ca.portal.admin

Local mode update and fastaccess

Discussion created by ca.portal.admin on Feb 6, 2008
Hi everyone:



We want to address a local mode update batch that runs for 20+ hours.



We have Fastaccess 7.0 with IDMS 15.0 SP5.



We want to implement Fastaccess into this local batch update job to get
it to run faster.



As always, you replies are appreciated in advance.



J. Wayne Doneker

BAE Systems

York Pa.,

717 225 8109

John.Doneker@baesystems.com


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








Normal

Normal
Re: Writing to a queue from a COBOL subprogram
"Joan --

Gary's suggestion is a good one.
Calling and called program are one task thread and two run-units (actually
three run-units if you count queue activity in the called program)

You mentioned that you don't want to do anything in the subprogram that
COMMITS work in the calling program.
That means you need to move all your COMMIT TASK and / or FINISH TASK work
to the calling program.

If you don't want to do that, then do a COMMIT ALL and then a FINISH in the
subprogram (since you are doing DB work in the called program, too).

I think doing the COMMIT ALL should be sufficient in your subprogram for the
queue work.
Queue work is actually done by a run-unit not even defined by your program
anyways.
Queue work is done by queue RHDCRUAL pre-allocated run-units which aren't
really going to FINISH anyways.
They are allocated at startup and idle all day long to handle queue work.
If you have heavy queue activity on your system that uses all pre-allocated
run-units, but needs one more for your task, an overflow RHDCRUAL is started
and then finished free of charge.

Thanks.
Jon Gocher

----- Original Message -----
From: ""Joan Hutchinson"" <JHUTCHIN@IPSCO.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Wednesday, February 06, 2008 10:23 AM
Subject: Re: Writing to a queue from a COBOL subprogram


Thanks to everyone for the many suggestions...I will do some experimenting
based on them and see what works best in this situation.
""Cherlet, Gary (JTS)"" <Cherlet.Gary@SAUGOV.SA.GOV.AU> 2/5/2008 3:51 PM
>
There have been many suggestions in this thread - one that I have not
seen is the use of COMMIT ALL in the subprogram. COMMIT ALL only affects
the one run unit - the ALL says to COMMIT both DB work AND Queue work.
This command will NOT impact any other run units associated with the
batch task. Note that there is also a COMMIT ALL TASK which would impact
other run units.

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:cherlet.gary@saugov.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.

Outcomes