IDMS

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 . . .

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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 

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

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

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 +?

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.

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

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

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

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

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

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 +?

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

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

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

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

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

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?

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

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
Original Message-----=0AFrom:=
IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]=0AOn Beha=
lf Of Trayler, Christopher=0ASent: Monday, October 19, 2009 11:55 AM=0ATo: =
IDMS-L@LISTSERV.IUASSN.COM=0ASubject: FW: Journal Offload with Fastaccess=
=0A=0AHi David=0A=0AI ran a quick test to see if I was ""out of date"". No I =
am not. QSAM does=0Astill work but I was wrong about the Archive being the =
target for QSAM.=0AIt is actually the input disk journal.=0A=0ACommand =3D=
=3D=3D>=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 =A0 =A0 =A0 1 RBN processed by O=
PEN for file J1JRNL=A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 30 QSAM B=
UFFERS will be used=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=
=A0 =A0 =A0 =A0 =A0 =A0 QSAM area is ARCHIVE.JOURNAL=A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 =A0 0 RBN processed by SKIP for fil=
e J1JRNL=A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 =A0 1 RBN processed =
by QSAM for file J1JRNL=A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A.=0A.=0A=A0 =A0 =A0 =
=A0 =A0 3 RBN processed by WRIT for file J1JRNL=A0 =A0 =A0 =A0 =A0 =0A=A0 =
=A0 =A0 =A0 =A0 3 RBN processed by CLOS for file J1JRNL=A0 =A0 =A0 =A0 =A0 =
=0A=A0 =A0 =A0 47,873 pages READ thru QSAM=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 =A0 41 pages READ thru BDAM=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 =A0 6 pages =
QSAM skipped=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=A0 =
=A0 =A0 =A0 =A0 30 QSAM BUFFERS used=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 =A0 =A0 QSAM area is ARCHIVE.JOURNA=
L=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 =0AEND OF JOURNAL ARCHIVE=A0 =A0 2009-10-19-11.35.59.820515=A0 =
=A0 =A0 =0AStatus =3D 0=A0 =A0 =A0 =A0 SQLSTATE =3D 00000=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0AClearly the process is using QSAM=
instead of BDAM and it is the input=0Adisk journal which is getting the QS=
AM push.=0A=0AThe question now is whether the advantages of using QSAM over=
BDAM have=0Abeen eroded over the years by the advances in hardware and cac=
hing. It=0Amay well be that when I first tried this solution (in my youth) =
that the=0Adifference was very marked but that technology has made it redun=
dant.=0ANeither do I have any recollection of how I came up with 30 as a ma=
gic=0Anumber.=0A=0AChris=0A=0A=A0 =A0 =0A=0A

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

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

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.

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
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 =3D=3D=3D> =20
1 RBN processed by OPEN for file J1JRNL =20
30 QSAM BUFFERS will be used =20
QSAM area is ARCHIVE.JOURNAL =20
0 RBN processed by SKIP for file J1JRNL =20
1 RBN processed by QSAM for file J1JRNL =20
.
.
3 RBN processed by WRIT for file J1JRNL =20
3 RBN processed by CLOS for file J1JRNL =20
47,873 pages READ thru QSAM =20
41 pages READ thru BDAM =20
6 pages QSAM skipped =20
30 QSAM BUFFERS used =20
QSAM area is ARCHIVE.JOURNAL =20
=20
END OF JOURNAL ARCHIVE 2009-10-19-11.35.59.820515 =20
Status =3D 0 SQLSTATE =3D 00000 =20

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

=20

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
"See CO97926. So probably not an epiphany......
=20
Like so many thing it's not in the manual.
=20
Cheers
Martin

_____ =20

From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Mon 19/10/2009 12:28
To: IDMS-L@LISTSERV.IUASSN.COM
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 =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

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
"See CO97926. So probably not an epiphany......

Like so many thing it's not in the manual.

Cheers
Martin

_____

From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Mon 19/10/2009 12:28
To: IDMS-L@LISTSERV.IUASSN.COM
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

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 would be surprised if any tool helps speed Journal offloads very much mos=
tly 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 of=
fload process was read only - unfortunately it's not. Because retained jour=
nal images for non-committed transactions are likely near the end of the jo=
urnal, 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 th=
e 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 r=
ead 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: Addressin=
g: If you have received this e-mail in error, please advise by reply e-mai=
l to the sender. Please also destroy the original transmission and its con=
tents. Confidentiality: This e-mail may contain confidential information w=
hich also may be legally privileged. Only the intended recipient(s) may ac=
cess, use, distribute or copy this e-mail. Individual Views: Unless otherw=
ise indicated, the views expressed are those of the sender, not Justice Tec=
hnology Services. Computer Viruses: It is the recipient's responsibility t=
o check the e-mail and any attached files for viruses.

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=3DARCHIVE.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

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 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 . . .=20
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 . . .=20
Well, it's back in now.
Regards,
dem