Re:question on QUED

[ca.portal.admin]

i have a very active read-only CV - however it does update Queues (being
r/o journals are very small)

although several applications have been subset - the jobs that write to
these queues are still active- so i execute QUED prompt
I note then when a journal fills and the info message is written

DC205030 V75 T53649733 LID=4179105942 PROG=RHDCRUAL SUBS=IDMSNWK7
BFOR=438KB

rhdcrual is the program - interestingly - even though i exit qued -
condensing does not free up the journal space

is this because a pre-defined (RHDCRUAL) run unit is considered still
active and as such the BFORS cannot be removed?

the DCMT D RUNUNIT shows:

TYPE QUEUE
DRIVER TASK ID 0000000002
SUBSCHEMA IDMSNWK7
NODE
DICTNAME/DBNAME SYSTEM
IDLE INTERVAL OFF
PREDEFINED RUN UNITS 2
RUN UNIT ALLOCATIONS 162
RUN UNIT FREES 162
OVERFLOW RUN UNITS 0
AREA NAME DDLDCRUN
USAGE MODE SHARED UPDATE
TYPE BOUND IN-USE ALLOCS OWNING TASK
PERM YES NO 161
PERM YES NO 1


Chris Hoelscher
IDMS/DB2 System & Database Architect
Humana Inc
502-476-2538
[e-mail]

I refuse to repeat gossip - so listen carefully the first time




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
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: question on QUED
"I think the problem is that the size of the journals does not fit the size =
of the queue area=2E QUED is the only app that sweeps the queue area, and =
does deletes=2E The journals have to be large enough to handle all the bef=
ore images and after immage s until QUED is done sweeping the whole area=2E=
I don't think QUED does commits=2E I don't know whether it would be advi=
sable to program it that way, but I don't see the harm in issueing frequent=
commits because if QUED abends, then it can be run again to clear out the =
rest of the queue=2E=0D=0A=0D=0ALutz Petzold=0D=0ADBSS DB2 LUW/IDMS Support=
=0D=0A401-782-2265=0D=0APage 860 366 0865 or Telalert=0D=0A=0D=0A=0D=0A=0D=
=0A =0D=0A=0D=0AThis e-mail may contain confidential or privileged informat=
ion=2E If=0Ayou think you have received this e-mail in error, please advise=
the=0Asender by reply e-mail and then delete this e-mail immediately=2E=0A=
Thank you=2E Aetna
"
IDMS 3rd-party providers forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: question on QUED
"I think the problem is that the size of the journals does not fit the size of the queue area. QUED is the only app that sweeps the queue area, and does deletes. The journals have to be large enough to handle all the before images and after immage s until QUED is done sweeping the whole area. I don't think QUED does commits. I don't know whether it would be advisable to program it that way, but I don't see the harm in issueing frequent commits because if QUED abends, then it can be run again to clear out the rest of the queue.

Lutz Petzold
DBSS DB2 LUW/IDMS Support
401-782-2265
Page 860 366 0865 or Telalert





This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: question on QUED
"Where do all these BFOR images come from that you're referring to? QUED re=
ads a record, deletes a record, maybe=2E At most there are two images=2E =
At best, only one BFOR image per record read=2E It's a sequential sweep, so=
no repetition of records read=2E So there is nothing to condense=2E No?=
=0D=0A=0D=0ALutz Petzold=0D=0ADBSS DB2 LUW/IDMS Support=0D=0A401-782-2265=
=0D=0APage 860 366 0865 or Telalert=0D=0A=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A---=
Original Message---=0D=0AFrom: IDMS Public Discussion Forum =0D=0A[mail=
To:IDMS-L@LISTSERV=2EIUASSN=2ECOM] On Behalf Of donjcasey@COMCAST=2ENET=0D=
=0ASent: Tuesday, September 21, 2010 10:26 AM=0D=0ATo: IDMS-L@LISTSERV=2EIU=
ASSN=2ECOM=0D=0ASubject: Re: question on QUED=0D=0A=0D=0AIgnore my previous=
answer=2E=2E=2E this fits circumstances better=2E =0D=0AIf QUED is still =
running when offload against J1 is run, the =0D=0ABFORs will be left behind=
=2E Since QUED is ERASEing, almost all =0D=0Aof the journal space is used =
for BFOR images, and very little =0D=0Awill compress until the next sweep t=
hrough=2E=0D=0A=0D=0ADon (still working on first cup of morning coffee) Cas=
ey=0D=0A=0D=0A