CA IDMS IUA EIUA

Expand all | Collapse all

Journal Offload with Fastaccess

  • 1.  Journal Offload with Fastaccess

    Posted 10-14-2009 09:03 PM
    Having been a former board member, I know I can get some
    straight information here. We have recently converted to
    unloading our journals using Virtual Tape (VTL) We have
    noticed very minimal improvement. We have the ASG product
    FastAccess. Has anyone used this product to unload their
    journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "No issues.
    But we did not see vast improvement there, either.
    We did see good improvement with VTS, vis a vis, tape mounts and IO
    speed, tho . . .


  • 2.  Re:Journal Offload with Fastaccess

    Posted 10-14-2009 09:03 PM
    Having been a former board member, I know I can get some
    straight information here. We have recently converted to
    unloading our journals using Virtual Tape (VTL) We have
    noticed very minimal improvement. We have the ASG product
    FastAccess. Has anyone used this product to unload their
    journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "I have always used QSAM - which is free - to speed up my journal
    offloads. It seems to work fine and is very quick.

    //SYSIN DD *
    ARCHIVE JOURNAL BUFFERS 30;
    //SYSIDMS DD *
    IDMSQSAM=ON
    QSAMAREA=ARCHIVE.JOURNAL
    QSAMBUF#=30
    /*

    Chris Trayler


  • 3.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 4.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 5.  Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 6.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 7.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 8.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 9.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 10.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 11.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 12.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 13.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 14.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 15.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8  8226 5199
    Facsimile  +61 (0)8  8226 5311
    Mobile      +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing:  If you have received this e-mail in error, please advise by
    reply e-mail to the sender.  Please also destroy the original
    transmission and its contents. Confidentiality:  This e-mail may contain
    confidential information which also may be legally privileged.  Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views:  Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 16.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 17.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 18.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 19.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 20.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 21.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 22.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 23.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 24.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 25.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 26.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 27.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 28.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 29.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 30.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 31.  Re:Re: Journal Offload with Fastaccess

    Posted 10-15-2009 01:36 AM
    I would be surprised if any tool helps speed Journal offloads very much
    mostly because of the condense phase - I would always expect Journal
    Offloads to be I/O bound on the journals themselves. It would be
    different if the offload process was read only - unfortunately it's not.
    Because retained journal images for non-committed transactions are
    likely near the end of the journal, and the space they are being
    condensed into would be at the start of the area - you would need
    database in memory (DBIM - massive big ""above the line' or ""above the
    bar"" buffers ) to make much difference - so that you don't get multiple
    read/writes to the same page. At a minimum you have to read every page
    at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary=20


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows:
    Addressing: If you have received this e-mail in error, please advise by
    reply e-mail to the sender. Please also destroy the original
    transmission and its contents. Confidentiality: This e-mail may contain
    confidential information which also may be legally privileged. Only the
    intended recipient(s) may access, use, distribute or copy this e-mail.
    Individual Views: Unless otherwise indicated, the views expressed are
    those of the sender, not Justice Technology Services. Computer Viruses:
    It is the recipient's responsibility to check the e-mail and any
    attached files for viruses.


  • 32.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight informati=
    on here. We have recently converted to unloading our journals using Virtua=
    l Tape (VTL) We have noticed very minimal improvement. We have the ASG pr=
    oduct FastAccess. Has anyone used this product to unload their journals? =
    If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Started task or Job?
    "Issues that come to mind are:

    1) Security - a manually submitted job will only have the RACF authorities of the person who submits the job - so there may be issues in terms of access privileges to the databases, journals and so forth - an automated operations or CA-7 job can have an ""owner"" user id with appropriate authorities

    2) System timer issues - I don't know the answer - but I wonder if started tasks can run ""forever"" whereas there may be time limits on submitted jobs?

    3) Priorities and workload manager - is it easier to give started tasks higher priorities and preferences to submitted jobs?

    I've never given this any thought - when doing initial installs I used to use manually submitted jobs until I had the system set up the way that I wanted it - as I had more control of start up and shut down without operator intervention (eg. if you can't issue console start task commands and reply to outstanding response). As a matter of course whenever I handed the system over to the user site the systems programmers always seemed to set it up as a started task - decision was never up to me.

    I know this won't help - but at least here's some food for thought - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows: Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents. Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services. Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.


  • 33.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    FW: Journal Offload with Fastaccess
    "Hi David

    I ran a quick test to see if I was ""out of date"". No I am not. QSAM does
    still work but I was wrong about the Archive being the target for QSAM.
    It is actually the input disk journal.

    Command ===>
    1 RBN processed by OPEN for file J1JRNL
    30 QSAM BUFFERS will be used
    QSAM area is ARCHIVE.JOURNAL
    0 RBN processed by SKIP for file J1JRNL
    1 RBN processed by QSAM for file J1JRNL
    .
    .
    3 RBN processed by WRIT for file J1JRNL
    3 RBN processed by CLOS for file J1JRNL
    47,873 pages READ thru QSAM
    41 pages READ thru BDAM
    6 pages QSAM skipped
    30 QSAM BUFFERS used
    QSAM area is ARCHIVE.JOURNAL

    END OF JOURNAL ARCHIVE 2009-10-19-11.35.59.820515
    Status = 0 SQLSTATE = 00000

    Clearly the process is using QSAM instead of BDAM and it is the input
    disk journal which is getting the QSAM push.

    The question now is whether the advantages of using QSAM over BDAM have
    been eroded over the years by the advances in hardware and caching. It
    may well be that when I first tried this solution (in my youth) that the
    difference was very marked but that technology has made it redundant.
    Neither do I have any recollection of how I came up with 30 as a magic
    number.

    Chris


  • 34.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.








    Reuters Limited, a Thomson Reuters company, is a company incorporated under the laws of England and Wales (registered number 145516) having its registered office and address for service at the Thomson Reuters Building, 30 South Colonnade, Canary Wharf, London, E145EP, United Kingdom.

    This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments.

    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "You may find this Epiphanic.

    Steve




    APAR
    Chris

    You may find this Epiphanic.

    Steve




     APAR #:  CO97926                                 DATE:    26 FEB 1993
     
     PROBLEM DESCRIPTION: ARCHIVE  JOURNAL  UTILITY  DOES  NOT  MAKE  USE  OF
                          IDMSQSAM  WHEN  THE  SYSIDMS  PARM  IDMSQSAM=ON  IS
                          SPECIFIED.
     
                      THE PROBLEM IS THAT UNLESS QSAMAREA= IS SPECIFIED,
                      QSAM PROCESSING WILL BE USED ON THE FIRST AREA
                      ENCOUNTERED (TYPICALLY THE DDLSEC FOR A SECURITY
                      CHECK), BUT QSAMAREA= IS MEANINGLESS FOR ARCHIVE
                      JOURNAL AS WE WISH TO USE QSAM AGAINST THE JOURNALS
                      NOT AN AREA.
     
                      THIS APAR WILL ALLOW QSAMAREA=ARCHIVE.JOURNAL TO BE
                      SPECIFIED IN THE SYSIDMS PARMS AND WILL RESULT IN
                      QSAM PROCESSING BEING USED AGAINST THE JOURNAL FILES.





    ________________________________
    From: ""Trayler, Christopher"" <christopher.trayler@JULIUSBAER.COM>
    To: IDMS-L@LISTSERV.IUASSN.COM
    Sent: Monday, 19 October, 2009 12:28:18
    Subject: Re: Journal Offload with Fastaccess

    You are right. I don't understand it either any more. There is no
    ARCHIVE.JOURNAL as far as I can make out. There is this:

        CREATE                                                       
        ARCHIVE JOURNAL S126DMCL.SYSJRNL                             
    *+      CREATED 2008-09-18-07.54.24.662683  BY PRZOPER         
            BLOCK SIZE 32760 CHARACTERS                             
            ASSIGN TO SYSJRNL                                       
            ;                                                       

    But that isn't the same thing at all. There is no customization. I have
    used the same trick at every IDMS site I have worked at and it is
    consistent.

    How did I find it in the first place? I can't remember. I probably
    knocked a journal offload over and found it in the dump. That's what I
    usually do if I need to rummage around in the internals. 

    I have been doing this job too long now. Sometime between 1976 and now I
    must have had an Epiphany.

    Chris 


  • 35.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.

    This E-Mail has been scanned for viruses.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Code pages and CCSID
    "Is it safe to assume that the alternate versions of RHDCCODE match the code=
    pages that are part of their names? For example, is CP1141F and/or CP1141=
    R the same as CCSID 1141?

    Kay Rozeboom
    State of Iowa
    Information Technology Enterprise
    Department of Administrative Services
    Telephone: 515.281.6139 Fax: 515.281.6137
    Email: Kay.Rozeboom@Iowa.Gov
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Code pages and CCSID
    "Is it safe to assume that the alternate versions of RHDCCODE match the code pages that are part of their names? For example, is CP1141F and/or CP1141R the same as CCSID 1141?

    Kay Rozeboom
    State of Iowa
    Information Technology Enterprise
    Department of Administrative Services
    Telephone: 515.281.6139 Fax: 515.281.6137
    Email: Kay.Rozeboom@Iowa.Gov
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    JREPORT=008
    "Hello All:



    Anybody know how to only create JREPORT=008 for a 10 minute time span?



    William M. Allen, Jr.

    ARCH Consulting Associates, Ltd.

    (704) 641-0296
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    JREPORT=008
    "Hello All:



    Anybody know how to only create JREPORT=008 for a 10 minute time span?



    William M. Allen, Jr.

    ARCH Consulting Associates, Ltd.

    (704) 641-0296
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Usermod for startup module
    "Laura,=20

    =20

    Job 9 in the base install process links the WTOEXIT into IDMSDC with a
    usermod.=20

    =20

    You should be able to remove the usermod with SMP and then re-apply it
    with the code in Job 9.=20

    =20

    If you are installing R17 SP1 on top of R17, this is exactly what you
    will have to do.=20

    =20

    I can send the JCL I used off-line if you wish.=20

    =20

    Nigel Salway

    Senior Analyst

    1900 Albert Street

    Regina, SK S4P 4K8

    Telephone: (306) 761-4063 =20

    Fax: (306) 761-4141 =20

    =20

    CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging
    to CGI Group Inc. and its affiliates may be contained in this message.
    If you are not a recipient indicated or intended in this message (or
    responsible for delivery of this message to such person), or you think
    for any reason that this message may have been addressed to you in
    error, you may not use or copy or deliver this message to anyone else.
    In such case, you should destroy this message and are asked to notify
    the sender by reply email.

    =20
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Usermod for startup module
    "Laura,



    Job 9 in the base install process links the WTOEXIT into IDMSDC with a
    usermod.



    You should be able to remove the usermod with SMP and then re-apply it
    with the code in Job 9.



    If you are installing R17 SP1 on top of R17, this is exactly what you
    will have to do.



    I can send the JCL I used off-line if you wish.



    Nigel Salway

    Senior Analyst

    1900 Albert Street

    Regina, SK S4P 4K8

    Telephone: (306) 761-4063

    Fax: (306) 761-4141



    CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging
    to CGI Group Inc. and its affiliates may be contained in this message.
    If you are not a recipient indicated or intended in this message (or
    responsible for delivery of this message to such person), or you think
    for any reason that this message may have been addressed to you in
    error, you may not use or copy or deliver this message to anyone else.
    In such case, you should destroy this message and are asked to notify
    the sender by reply email.


    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: JREPORT=008
    "yes - but only if you are willing to do a bit of work
    a SELECT/BYPASS does not appear to work because at the time of reading the
    record from the journal file the date/time stamps are in binary (SQL?)
    format

    so you would need to modify the JREPORT008 report a bit as follows

    if (WK-DTETI < 'HH:MM:SS:FF') or (WK-DTETI GT 'HH:MM:SS:FF') drop

    at the time jreport 8 gets control - jreport 000 has done all the
    conversions needed

    if you need to look at date - WK-DTEB contains the date in the format
    'MM/DD/' (do the date check first)


    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly






    From:
    ""William M. Allen, Jr."" <archcons@BELLSOUTH.NET>
    To:
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    Date:
    10/20/2009 05:14 PM
    Subject:
    [IDMSVENDOR-L] JREPORT=008
    Sent by:
    IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



    Hello All:



    Anybody know how to only create JREPORT=008 for a 10 minute time span?



    William M. Allen, Jr.

    ARCH Consulting Associates, Ltd.

    (704) 641-0296



    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: [IDMSVENDOR-L] JREPORT=008
    "yes - but only if you are willing to do a bit of work
    a SELECT/BYPASS does not appear to work because at the time of reading the
    record from the journal file the date/time stamps are in binary (SQL?)
    format

    so you would need to modify the JREPORT008 report a bit as follows

    if (WK-DTETI < 'HH:MM:SS:FF') or (WK-DTETI GT 'HH:MM:SS:FF') drop

    at the time jreport 8 gets control - jreport 000 has done all the
    conversions needed

    if you need to look at date - WK-DTEB contains the date in the format
    'MM/DD/' (do the date check first)


    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly






    From:
    ""William M. Allen, Jr."" <archcons@BELLSOUTH.NET>
    To:
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    Date:
    10/20/2009 05:14 PM
    Subject:
    [IDMSVENDOR-L] JREPORT=008
    Sent by:
    IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



    Hello All:



    Anybody know how to only create JREPORT=008 for a 10 minute time span?



    William M. Allen, Jr.

    ARCH Consulting Associates, Ltd.

    (704) 641-0296



    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    additional info on jreport 008 and time-based reporting
    "ya know - sometimes i think they should take away my license to post on
    idms-l

    much of what i posted previously was misleading (read WRONG)

    since the timestamps i referred to are NOT on bfor/aftr records - one
    would need to attack the jreport on 3 steps

    1) identify the run units that started or ended during the service
    2) go back and get all bfors/aftrs for those run units

    3) if you had a run unit that either started before or ended after the
    time period, try to find a bgin/endj/comt closest to the endpoints of the
    time period - note their sequence numbers - and then exclude BFORS/AFTRS
    that fell before the sequence# that corresponds to the beginning of the
    time period, or falls after the sequence# that corresponds to the end of
    the time period

    i hope this is closer to correct - it is late in the Eastern (US) Time
    Zone





    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly




    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    additional info on jreport 008 and time-based reporting
    "ya know - sometimes i think they should take away my license to post on
    idms-l

    much of what i posted previously was misleading (read WRONG)

    since the timestamps i referred to are NOT on bfor/aftr records - one
    would need to attack the jreport on 3 steps

    1) identify the run units that started or ended during the service
    2) go back and get all bfors/aftrs for those run units

    3) if you had a run unit that either started before or ended after the
    time period, try to find a bgin/endj/comt closest to the endpoints of the
    time period - note their sequence numbers - and then exclude BFORS/AFTRS
    that fell before the sequence# that corresponds to the beginning of the
    time period, or falls after the sequence# that corresponds to the end of
    the time period

    i hope this is closer to correct - it is late in the Eastern (US) Time
    Zone





    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly




    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: additional info on jreport 008 and time-based reporting
    "Without having my documentation in front of me: I think this is a two pass
    operation:

    1) Run a jreport 8 selecting for TIME records that meet the time
    requirements.

    2) Use the journal sequence number information from that report to run a
    report that selects on journal sequence number.

    Don Casey
    Principal Consultant
    Run Right, LLC


  • 36.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "We use QSAM for our Journal offloads. Within the Common (use CV symbolic) Journal Proc we have a SYSIDMS statement of:
    //SYSIDMS DD DSN=DBA2.SYSIDMS.PARMS(ARCHSYSI),DISP=SHR

    ARCHSYSI DBA2.SYSIDMS.PARMS(ARCHSYSI) Contains:
    000001 IDMSQSAM=ON
    000002 QSAMAREA=ARCHIVE.JOURNAL
    000003 QSAMBUF#=21


  • 37.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "What was the timings using QSAM? Or was that the 2 min +?


  • 38.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "Hi David

    It is a good question. And one to which I don't know the answer - yet. I
    can vaguely remember doing the research to come to this arrangement but
    it was many years ago and was probably R12 or possibly even R10.2. I
    haven't reviewed it since - it has just stayed in the offload job and
    now I am R17.

    I may well have distributed ""out of date"" advice. I shall review it -
    and if it is no longer effective - remove it.

    I do know that our offloads go to disk and then afterwards to tape. The
    technique certainly wouldn't work with direct tape writing. The intended
    target for the QSAM processing is definitely the offloaded journal
    archive not the disk journals.

    If my advice is an outdated ""red herring"" then I apologise.

    Chris Trayler

    BTW. It wouldn't be BUFFERSTAT that shows the difference. You might get
    some information with QSAMTRACE=ON. I shall try it.


  • 39.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "You are right. I don't understand it either any more. There is no
    ARCHIVE.JOURNAL as far as I can make out. There is this:

    CREATE
    ARCHIVE JOURNAL S126DMCL.SYSJRNL
    *+       CREATED 2008-09-18-07.54.24.662683   BY PRZOPER
    BLOCK SIZE 32760 CHARACTERS
    ASSIGN TO SYSJRNL
    ;

    But that isn't the same thing at all. There is no customization. I have
    used the same trick at every IDMS site I have worked at and it is
    consistent.

    How did I find it in the first place? I can't remember. I probably
    knocked a journal offload over and found it in the dump. That's what I
    usually do if I need to rummage around in the internals.

    I have been doing this job too long now. Sometime between 1976 and now I
    must have had an Epiphany.

    Chris


  • 40.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "You know,
    OTOH,
    FAST ACCESS is a really smart piece of software . . .I just let him
    figger everything out. . . and it does seem to make an empirical
    difference . . .
    I forget why we had taken it out of our Journal & LOG archives . . .
    something related to our implementation of IDMS 16.0, just procedural,
    not technical . . .
    Well, it's back in now.
    Regards,
    dem


  • 41.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.








    Reuters Limited, a Thomson Reuters company, is a company incorporated
    under the laws of England and Wales (registered number 145516) having
    its registered office and address for service at the Thomson Reuters
    Building, 30 South Colonnade, Canary Wharf, London, E145EP, United
    Kingdom.

    This e-mail is for the sole use of the intended recipient and contains
    information that may be privileged and/or confidential. If you are not
    an intended recipient, please notify the sender by return e-mail and
    delete this e-mail and any attachments.

    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "Oh well found! So I was partly right. It was in the 12.0 days that I
    coded it 16 years ago. That would explain why the other guys in the
    office don't remember because they were in school at the time.

    So it would appear that, allowing for the passage of years, that an
    Epiphany is effectively indistinguishable from 6 pints of Stella at
    lunch time.=20

    I can't do that any more either.

    Chris

    P.S. Long time no see Martin. Are you going to the UKIUA on 10 Nov?=20


  • 42.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "Well, this'd be my last word on this, but I have to say that FastAccess
    makes a HUGE difference . . . this might be hardware related, since we
    now use PAVs and a much faster CPU, but lookit:

    Plain Vanilla Journal Archive average 2.6 minutes (14 archive jobs)
    FAST ACCESS Journal Archive average .28 minutes (22 archive jobs)

    We have 8 journals of 160,000 pages each.
    All of these jobs ran during prime shift.

    But I reckon that is a 10-fold improvement in performance. Hard to
    ignore.
    No parameter tuning for Fast Access used, either.
    As I say, I like to let it figger out what's what.

    dem


  • 43.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.

    This E-Mail has been scanned for viruses.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "Plain vanilla, no QSAM.

    dem


  • 44.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.

    This E-Mail has been scanned for viruses.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "What was the timings using QSAM? Or was that the 2 min +?


  • 45.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.

    This E-Mail has been scanned for viruses.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "Plain vanilla, no QSAM.

    dem


  • 46.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "You are right. I don't understand it either any more. There is no
    ARCHIVE.JOURNAL as far as I can make out. There is this:

    CREATE =20
    ARCHIVE JOURNAL S126DMCL.SYSJRNL =20
    *+       CREATED 2008-09-18-07.54.24.662683   BY PRZOPER          =20
    BLOCK SIZE 32760 CHARACTERS =20
    ASSIGN TO SYSJRNL =20
    ; =20

    But that isn't the same thing at all. There is no customization. I have
    used the same trick at every IDMS site I have worked at and it is
    consistent.

    How did I find it in the first place? I can't remember. I probably
    knocked a journal offload over and found it in the dump. That's what I
    usually do if I need to rummage around in the internals. =20

    I have been doing this job too long now. Sometime between 1976 and now I
    must have had an Epiphany.

    Chris =20


  • 47.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "When we say QSAMAREA=ARCHIVE.JOURNAL, what does that mean?

    My cursory examination of the manuals was unproductive . . .

    Is this an internal ""trick"", knowing that the Archive Journal will be
    treated as an Area ARCHIVE.JOURNAL, or is it a customization at your
    shop?

    Can you please display ARCHIVE.JOURNAL in OCF and share that with me?

    Regards,
    dem


  • 48.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.




    =20
    =20
    =20
    =20
    Reuters Limited, a Thomson Reuters company, is a company incorporated
    under the laws of England and Wales (registered number 145516) having
    its registered office and address for service at the Thomson Reuters
    Building, 30 South Colonnade, Canary Wharf, London, E145EP, United
    Kingdom.
    =20
    This e-mail is for the sole use of the intended recipient and contains
    information that may be privileged and/or confidential. If you are not
    an intended recipient, please notify the sender by return e-mail and
    delete this e-mail and any attachments.
    =20
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "Well, this'd be my last word on this, but I have to say that FastAccess
    makes a HUGE difference . . . this might be hardware related, since we
    now use PAVs and a much faster CPU, but lookit:

    Plain Vanilla Journal Archive average 2.6 minutes (14 archive jobs)
    FAST ACCESS Journal Archive average .28 minutes (22 archive jobs)

    We have 8 journals of 160,000 pages each.
    All of these jobs ran during prime shift.

    But I reckon that is a 10-fold improvement in performance. Hard to
    ignore.
    No parameter tuning for Fast Access used, either.
    As I say, I like to let it figger out what's what.

    dem


  • 49.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: [IDMSVENDOR-L] Journal Offload with FastAccess
    "we use ASG-FastAccess for our Journal offloads at every shop for which I
    have worked. my only word of caution would be to specify PREFETCH=OFF on
    any job (journal offload or otherwise) where the possibility of PREFETCH
    engaging is possible.

    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly





    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "we use ASG-FastAccess for our Journal offloads at every shop for which I
    have worked. my only word of caution would be to specify PREFETCH=OFF on
    any job (journal offload or otherwise) where the possibility of PREFETCH
    engaging is possible.

    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly





    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDMSDC startup module
    "i never used the IDMSDC module prior to release 17 - prior to release 17
    i used a separate startup for each CV (because each had different #DCPARMS
    values)

    here is what i used prior to 17

    first a UCLIN USERMOD to isolate the skeleton from the actual generation
    (with only one startup module, this may not be necessary):

    //SMPPROC PROC
    //SMPGO EXEC PGM=GIMSMP,REGION=4096K,PARM='DATE=U'
    //SMPCSI DD DISP=SHR,DSN=IDMS.R150.IDMS.CSI
    //SMPHOLD DD DUMMY
    //SMPCNTL DD DDNAME=SYSIN
    // PEND
    /*
    //UMJCLIN EXEC PGM=IEBGENER
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD DUMMY
    //SYSUT1 DD DATA,DLM='%%'
    ++USERMOD(STRTJCL) DESC(BUILD JCL TEMPLATE FOR STARTUPS).
    ++VER(Z038) FMID(CGJF000).
    ++JCLIN.
    //CAIDMS JOB (12345),'CA-IDMS/DB INSTALL' THIS JOB CARD OK AS IS
    //JCLIN023 EXEC PGM=IEWL,PARM='LET,MAP,LIST,NCAL'
    //DISTLOAD DD DSN=DO.NOT.CHANGE.DISTLOAD,DISP=SHR
    //SYSLMOD DD DSN=DBALOAD,DISP=SHR
    //SYSLIN DD *
    INCLUDE DISTLOAD(PARMS023) <=== the member in ppoption for #DCparms

    INCLUDE DISTLOAD(RHDCOESA)
    INCLUDE DISTLOAD(RHDCOMWP)
    INCLUDE DISTLOAD(RHDCOMOC)
    INCLUDE DISTLOAD(RHDCHPCS)
    INCLUDE DISTLOAD(RHDCACHE)
    INCLUDE DISTLOAD(WTOX023) <=== the member in ppoption for WTOEXIT (i
    did have a separate (but identical) wtoexit source for each CV
    ENTRY STARTUP
    NAME IDMSDC23(R) <=== the startup module name

    followed by the generate USERMOD

    //SMPPROC PROC
    //SMPGO EXEC PGM=GIMSMP,REGION=4096K,PARM='DATE=U'
    //SMPCSI DD DISP=SHR,DSN=IDMS.R150.IDMS.CSI
    //SMPHOLD DD DUMMY
    //SMPCNTL DD DDNAME=SYSIN
    // PEND
    /*
    //*-----------------------------------*
    //* RECEIVE *
    //*-----------------------------------*
    //REC#SRC EXEC SMPPROC
    //SMPPTFIN DD *
    ++USERMOD(START23)
    DESC(CREATE STARTUP MODULE FOR CV23).
    ++VER(Z038) FMID(CGJF000).
    ++SRC(PARMS023) DISTLIB(DISTSRC) DISTMOD(DISTLOAD) TXLIB(PPOPTION).
    ++SRC(WTOX023) DISTLIB(DISTSRC) DISTMOD(DISTLOAD) TXLIB(PPOPTION).
    //SYSIN DD *
    SET BOUNDARY(GLOBAL).
    RECEIVE SELECT(START23).
    /*
    //*-----------------------------------*
    //* APPLY CHECK *
    //*-----------------------------------*
    //APPC#SRC EXEC SMPPROC,COND=(4,LT,REC#SRC.SMPGO)
    //SYSIN DD *
    SET BOUNDARY(IDMSTGT).
    APPLY CHECK SELECT(START23).
    /*
    //*-----------------------------------*
    //* APPLY *
    //*-----------------------------------*
    //APPLYSRC EXEC SMPPROC,
    // COND=(0,LT,APPC#SRC.SMPGO)
    //SYSIN DD *
    SET BOUNDARY(IDMSTGT).
    APPLY SELECT(START23).
    /*
    //


    now if you do not want to disturb the original IDMSDC that was delivered -
    then attempt the following
    1) modify the SYSLMOD dsname to be something different than wherever it
    went before the TARGET loadlib
    2) name the NAME something other than IDMSDC
    3) make IDMSDC an ALIAS in the linkedit step

    then - you can copy that module (and alias) into your runtime library


    starting with release 17 - this all (for me) became moot - all the options
    i would ever use are PARMable - so i now use the default IDMSDC


    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly






    From:
    Laura Rochon <l.rochon@VIDEOTRON.CA>
    To:
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    Date:
    10/19/2009 11:39 AM
    Subject:
    [IDMSVENDOR-L] IDMSDC startup module
    Sent by:
    IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



    Hi everyone,

    Looking for a SMP expert... Chris???

    We will be upgrading our op sys, and need to relink the IDMSDC startup
    module and the SVC. We use the common IDMSDC startup module for all our
    CVs. We do everything within SMP, so of course, would like to have a
    usermod to relink the IDMSDC startup module and the SVC. I've found a
    usermod for the svc, but haven't found one for the IDMSDC startup module
    as it's part of the base install.

    Anyone out there have a usermod to relink the IDMSDC startup module ?

    Thank you,
    Laura Rochon
    Ajilon



    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "We use QSAM for our Journal offloads. Within the Common (use CV symbolic) =
    Journal Proc we have a SYSIDMS statement of:
    //SYSIDMS DD DSN=3DDBA2.SYSIDMS.PARMS(ARCHSYSI),DISP=3DSHR

    ARCHSYSI DBA2.SYSIDMS.PARMS(ARCHSYSI) Contains:
    000001 IDMSQSAM=3DON =20
    000002 QSAMAREA=3DARCHIVE.JOURNAL =20
    000003 QSAMBUF#=3D21 =20


  • 50.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    IDMSDC startup module
    "Hi everyone,

    Looking for a SMP expert... Chris???

    We will be upgrading our op sys, and need to relink the IDMSDC startup
    module and the SVC. We use the common IDMSDC startup module for all our
    CVs. We do everything within SMP, so of course, would like to have a
    usermod to relink the IDMSDC startup module and the SVC. I've found a
    usermod for the svc, but haven't found one for the IDMSDC startup module
    as it's part of the base install.

    Anyone out there have a usermod to relink the IDMSDC startup module ?

    Thank you,
    Laura Rochon
    Ajilon
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "Oh well found! So I was partly right. It was in the 12.0 days that I
    coded it 16 years ago. That would explain why the other guys in the
    office don't remember because they were in school at the time.

    So it would appear that, allowing for the passage of years, that an
    Epiphany is effectively indistinguishable from 6 pints of Stella at
    lunch time.

    I can't do that any more either.

    Chris

    P.S. Long time no see Martin. Are you going to the UKIUA on 10 Nov?


  • 51.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    This E-Mail has been scanned for viruses.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: [IDMSVENDOR-L] IDMSDC startup module
    "i never used the IDMSDC module prior to release 17 - prior to release 17
    i used a separate startup for each CV (because each had different #DCPARMS
    values)

    here is what i used prior to 17

    first a UCLIN USERMOD to isolate the skeleton from the actual generation
    (with only one startup module, this may not be necessary):

    //SMPPROC PROC
    //SMPGO EXEC PGM=GIMSMP,REGION=4096K,PARM='DATE=U'
    //SMPCSI DD DISP=SHR,DSN=IDMS.R150.IDMS.CSI
    //SMPHOLD DD DUMMY
    //SMPCNTL DD DDNAME=SYSIN
    // PEND
    /*
    //UMJCLIN EXEC PGM=IEBGENER
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD DUMMY
    //SYSUT1 DD DATA,DLM='%%'
    ++USERMOD(STRTJCL) DESC(BUILD JCL TEMPLATE FOR STARTUPS).
    ++VER(Z038) FMID(CGJF000).
    ++JCLIN.
    //CAIDMS JOB (12345),'CA-IDMS/DB INSTALL' THIS JOB CARD OK AS IS
    //JCLIN023 EXEC PGM=IEWL,PARM='LET,MAP,LIST,NCAL'
    //DISTLOAD DD DSN=DO.NOT.CHANGE.DISTLOAD,DISP=SHR
    //SYSLMOD DD DSN=DBALOAD,DISP=SHR
    //SYSLIN DD *
    INCLUDE DISTLOAD(PARMS023) <=== the member in ppoption for #DCparms

    INCLUDE DISTLOAD(RHDCOESA)
    INCLUDE DISTLOAD(RHDCOMWP)
    INCLUDE DISTLOAD(RHDCOMOC)
    INCLUDE DISTLOAD(RHDCHPCS)
    INCLUDE DISTLOAD(RHDCACHE)
    INCLUDE DISTLOAD(WTOX023) <=== the member in ppoption for WTOEXIT (i
    did have a separate (but identical) wtoexit source for each CV
    ENTRY STARTUP
    NAME IDMSDC23(R) <=== the startup module name

    followed by the generate USERMOD

    //SMPPROC PROC
    //SMPGO EXEC PGM=GIMSMP,REGION=4096K,PARM='DATE=U'
    //SMPCSI DD DISP=SHR,DSN=IDMS.R150.IDMS.CSI
    //SMPHOLD DD DUMMY
    //SMPCNTL DD DDNAME=SYSIN
    // PEND
    /*
    //*-----------------------------------*
    //* RECEIVE *
    //*-----------------------------------*
    //REC#SRC EXEC SMPPROC
    //SMPPTFIN DD *
    ++USERMOD(START23)
    DESC(CREATE STARTUP MODULE FOR CV23).
    ++VER(Z038) FMID(CGJF000).
    ++SRC(PARMS023) DISTLIB(DISTSRC) DISTMOD(DISTLOAD) TXLIB(PPOPTION).
    ++SRC(WTOX023) DISTLIB(DISTSRC) DISTMOD(DISTLOAD) TXLIB(PPOPTION).
    //SYSIN DD *
    SET BOUNDARY(GLOBAL).
    RECEIVE SELECT(START23).
    /*
    //*-----------------------------------*
    //* APPLY CHECK *
    //*-----------------------------------*
    //APPC#SRC EXEC SMPPROC,COND=(4,LT,REC#SRC.SMPGO)
    //SYSIN DD *
    SET BOUNDARY(IDMSTGT).
    APPLY CHECK SELECT(START23).
    /*
    //*-----------------------------------*
    //* APPLY *
    //*-----------------------------------*
    //APPLYSRC EXEC SMPPROC,
    // COND=(0,LT,APPC#SRC.SMPGO)
    //SYSIN DD *
    SET BOUNDARY(IDMSTGT).
    APPLY SELECT(START23).
    /*
    //


    now if you do not want to disturb the original IDMSDC that was delivered -
    then attempt the following
    1) modify the SYSLMOD dsname to be something different than wherever it
    went before the TARGET loadlib
    2) name the NAME something other than IDMSDC
    3) make IDMSDC an ALIAS in the linkedit step

    then - you can copy that module (and alias) into your runtime library


    starting with release 17 - this all (for me) became moot - all the options
    i would ever use are PARMable - so i now use the default IDMSDC


    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com

    you only need to test the programs that you want to work correctly






    From:
    Laura Rochon <l.rochon@VIDEOTRON.CA>
    To:
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    Date:
    10/19/2009 11:39 AM
    Subject:
    [IDMSVENDOR-L] IDMSDC startup module
    Sent by:
    IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



    Hi everyone,

    Looking for a SMP expert... Chris???

    We will be upgrading our op sys, and need to relink the IDMSDC startup
    module and the SVC. We use the common IDMSDC startup module for all our
    CVs. We do everything within SMP, so of course, would like to have a
    usermod to relink the IDMSDC startup module and the SVC. I've found a
    usermod for the svc, but haven't found one for the IDMSDC startup module
    as it's part of the base install.

    Anyone out there have a usermod to relink the IDMSDC startup module ?

    Thank you,
    Laura Rochon
    Ajilon



    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with FastAccess
    "This is a reference to QSAMAREA=3DARCHIVE.JOURNAL, Since it worked on R15 a=
    nd R16
    I must assume it is being carried forward.=20
    =20
    Solutions Details
    Operating System: CMS Solution NTo: 615=20
    Confirmed Date: 02/26/1993 Updated Date: 02/27/1993 =20
    ComponSent: CA IDMS/DB-IDMS Release: 12.0=20
    Fix: CO97926 Hyper: No=20
    Distribution Code: AVAILABLE =20
    Problem Description Solution Downloads |Dependencies |Related Problems=20
    Problem Description=20
    Title: ARCHIVE JOURNAL UTILITY DOES NOT MAKE USE OF =20
    Description:=20
    PRODUCT: CA-IDMS/DB-MVS/VSE/VM =20
    RELEASE: C.0 APAR #: CO97926
    DATE: 26 FEB 1993 =20
    PROBLEM DESCRIPTION: ARCHIVE JOURNAL UTILITY DOES NOT MAKE USE OF
    IDMSQSAM WHEN THE SYSIDMS PARM IDMSQSAM=3DON IS SPECIFIED.
    THE PROBLEM IS THAT UNLESS QSAMAREA=3D IS SPECIFIED,
    QSAM PROCESSING WILL BE USED ON THE FIRST AREA ENCOUNTERED=20
    (TYPICALLY THE DDLSEC FOR A SECURITY CHECK), BUT QSAMAREA=3D IS
    MEANINGLESS FOR ARCHIVE JOURNAL AS WE WISH TO USE QSAM AGAINST THE JOUR=
    NALS=20
    NOT AN AREA.

    THIS APAR WILL ALLOW QSAMAREA=3DARCHIVE.JOURNAL TO BE SPECIFIED IN THE
    SYSIDMS PARMS AND WILL RESULT IN QSAM PROCESSING BEING USED AGAINST THE =
    JOURNAL FILES. =20
    =20
    =20
    =20
    =20


  • 52.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here.  We have recently converted to unloading our journals
    using Virtual Tape (VTL)  We have noticed very minimal improvement.  We
    have the ASG product FastAccess.  Has anyone used this product to unload
    their journals?  If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.

    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "You may find this Epiphanic.

    Steve




    APAR=

    Chris =0A=0AYou may find this Epiphanic. =0A=0ASteve =0A=0A=0A=0A=0A=A0APAR=
    #:=A0 CO97926=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DATE:=A0=A0=A0 26 FEB 1993=0A=A0=0A=A0=
    PROBLEM DESCRIPTION: ARCHIVE=A0 JOURNAL=A0 UTILITY=A0 DOES=A0 NOT=A0 MAKE=
    =A0 USE=A0 OF=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
    =A0=A0 IDMSQSAM=A0 WHEN=A0 THE=A0 SYSIDMS=A0 PARM=A0 IDMSQSAM=3DON=A0 IS=0A=
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SPECIFIED.=
    =0A=A0=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 THE PROBLEM IS=
    THAT UNLESS QSAMAREA=3D IS SPECIFIED,=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
    =A0=A0=A0=A0=A0=A0 QSAM PROCESSING WILL BE USED ON THE FIRST AREA=0A=A0=A0=
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ENCOUNTERED (TYPICALLY THE DD=
    LSEC FOR A SECURITY=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 C=
    HECK), BUT QSAMAREA=3D IS MEANINGLESS FOR ARCHIVE=0A=A0=A0=A0=A0=A0=A0=A0=
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 JOURNAL AS WE WISH TO USE QSAM AGAINST THE J=
    OURNALS=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NOT AN AREA.=
    =0A=A0=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 THIS APAR WILL=
    ALLOW QSAMAREA=3DARCHIVE.JOURNAL TO BE=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
    =A0=A0=A0=A0=A0=A0 SPECIFIED IN THE SYSIDMS PARMS AND WILL RESULT IN=0A=A0=
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 QSAM PROCESSING BEING USED=
    AGAINST THE JOURNAL FILES.=0A=0A=0A=0A=0A=0A______________________________=
    __=0AFrom: ""Trayler, Christopher"" <christopher.trayler@JULIUSBAER.COM>=0ATo=
    : IDMS-L@LISTSERV.IUASSN.COM=0ASent: Monday, 19 October, 2009 12:28:18=0ASu=
    Subject: Re: Journal Offload with Fastaccess=0A=0AYou are right. I don't unde=
    rstand it either any more. There is no=0AARCHIVE.JOURNAL as far as I can ma=
    ke out. There is this:=0A=0A=A0 =A0 CREATE=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
    =A0 =0A=A0 =A0 ARCHIVE JOURNAL S126DMCL.SYSJRNL=A0 =A0 =A0 =A0 =A0 =A0 =A0=
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A*+=A0 =A0 =A0 CREATED 2008-09-18-07.54.=
    24.662683=A0 BY PRZOPER=A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 BLOCK SIZE 32=
    760 CHARACTERS=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
    =0A=A0 =A0 =A0 =A0 ASSIGN TO SYSJRNL=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 ;=A0 =A0 =A0 =
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
    =A0 =A0 =A0 =A0 =A0 =A0 =0A=0ABut that isn't the same thing at all. There =
    is no customization. I have=0Aused the same trick at every IDMS site I have=
    worked at and it is=0Aconsistent.=0A=0AHow did I find it in the first plac=
    e? I can't remember. I probably=0Aknocked a journal offload over and found =
    it in the dump. That's what I=0Ausually do if I need to rummage around in t=
    he internals.=A0 =0A=0AI have been doing this job too long now. Sometime be=
    tween 1976 and now I=0Amust have had an Epiphany.=0A=0AChris=A0 =0A=0A-----=
    Original Message-----=0AFrom: IDMS Public Discussion Forum [mailTo:IDMS-L@L=
    ISTSERV.IUASSN.COM]=0AOn Behalf Of David E Matthews (DHL CZ)=0ASent: Montag=
    , 19. Oktober 2009 12:45=0ATo: IDMS-L@LISTSERV.IUASSN.COM=0ASubject: Re: Jo=
    urnal Offload with Fastaccess=0A=0AWhen we say QSAMAREA=3DARCHIVE.JOURNAL, =
    what does that mean?=0A=0AMy cursory examination of the manuals was unprodu=
    ctive . . .=0A=0AIs this an internal ""trick"", knowing that the Archive Jour=
    nal will be=0Atreated as an Area ARCHIVE.JOURNAL, or is it a customization =
    at your=0Ashop?=0A=0ACan you please display ARCHIVE.JOURNAL in OCF and shar=
    e that with me?=0A=0ARegards,=0Adem=0A=0A


  • 53.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "I tried this, but the BUFFERSTAT didn't show anything related to
    ARCHIVE.JOURNAL . . . and empirically, it didn't seem to make much
    difference . . . then I wondered if whether we should use instead
    QSAMAREA=GLBLDMCL.J1JRNL
    Etc for each . . .
    ?
    dem


  • 54.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended
    recipient only and may contain confidential or privileged information.
    If you have received this e-mail by mistake, please contact us
    immediately and completely delete it (and any attachments) and do not
    forward it or inform any other person of its contents. If you send us
    messages by e-mail, we take this as your authorization to correspond
    with you by e-mail, however, we will not accept the electronic
    transmission of orders/instructions without a specific agreement being
    in place to govern the same. If you do not wish to receive any further
    e-mail correspondence please let us know. E-mail transmission cannot be
    guaranteed to be secure or error-free as information could be
    intercepted, amended, corrupted, lost, destroyed, arrive late or
    incomplete, or contain viruses. Neither the Julius Baer Group nor the
    sender accept liability for any errors or omissions in the content of
    this message which arise as a result of its e-mail transmission. Please
    note that all e-mail communications to and from the Julius Baer Group
    may be monitored. This communication is for informational purposes only.
    It is not intended as an offer or solicitation for the purchase or sale
    of any financial instrument or as an official confirmation of any
    transaction.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "Hi David

    It is a good question. And one to which I don't know the answer - yet. I
    can vaguely remember doing the research to come to this arrangement but
    it was many years ago and was probably R12 or possibly even R10.2. I
    haven't reviewed it since - it has just stayed in the offload job and
    now I am R17.

    I may well have distributed ""out of date"" advice. I shall review it -
    and if it is no longer effective - remove it.

    I do know that our offloads go to disk and then afterwards to tape. The
    technique certainly wouldn't work with direct tape writing. The intended
    target for the QSAM processing is definitely the offloaded journal
    archive not the disk journals.=20

    If my advice is an outdated ""red herring"" then I apologise.

    Chris Trayler

    BTW. It wouldn't be BUFFERSTAT that shows the difference. You might get
    some information with QSAMTRACE=3DON. I shall try it. =20


  • 55.  Re:Journal Offload with Fastaccess

    Posted 10-15-2009 05:33 AM
    Having been a former board member, I know I can get some straight
    information here. We have recently converted to unloading our journals
    using Virtual Tape (VTL) We have noticed very minimal improvement. We
    have the ASG product FastAccess. Has anyone used this product to unload
    their journals? If so, have there been any issues?

    Thanks for any feedback,
    Steve Nason
    *****JuliusBaer Disclaimer***** This e-mail is for the intended =
    recipient only and may contain confidential or privileged information. =
    If you have received this e-mail by mistake, please contact us =
    immediately and completely delete it (and any attachments) and do not =
    forward it or inform any other person of its contents. If you send us =
    messages by e-mail, we take this as your authorization to correspond =
    with you by e-mail, however, we will not accept the electronic =
    transmission of orders/instructions without a specific agreement being =
    in place to govern the same. If you do not wish to receive any further =
    e-mail correspondence please let us know. E-mail transmission cannot be =
    guaranteed to be secure or error-free as information could be =
    intercepted, amended, corrupted, lost, destroyed, arrive late or =
    incomplete, or contain viruses. Neither the Julius Baer Group nor the =
    sender accept liability for any errors or omissions in the content of =
    this message which arise as a result of its e-mail transmission. Please =
    note that all e-mail communications to and from the Julius Baer Group =
    may be monitored. This communication is for informational purposes only. =
    It is not intended as an offer or solicitation for the purchase or sale =
    of any financial instrument or as an official confirmation of any =
    transaction.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Journal Offload with Fastaccess
    "I would be surprised if any tool helps speed Journal offloads very much mostly because of the condense phase - I would always expect Journal Offloads to be I/O bound on the journals themselves. It would be different if the offload process was read only - unfortunately it's not. Because retained journal images for non-committed transactions are likely near the end of the journal, and the space they are being condensed into would be at the start of the area - you would need database in memory (DBIM - massive big ""above the line' or ""above the bar"" buffers ) to make much difference - so that you don't get multiple read/writes to the same page. At a minimum you have to read every page at least once - and likely write every page at least once.

    Just my guess as to why ""go quick"" products don't help Journal unloads.

    HTH - cheers - Gary


    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    Telephone +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:gary.cherlet@sa.gov.au

    This e-mail message and any attachments are qualified as follows: Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents. Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services. Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.


  • 56.  Re:Journal Offload with Fastaccess