ca.portal.admin

Re:question on QUED

Discussion created by ca.portal.admin on Sep 21, 2010
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
choelscher@humana.com

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
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
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
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
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
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
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----- Original Message -----=0D=0AFrom: peter g charles <pete=
r=2Eg=2Echarles@BT=2ECOM>=0D=0ATo: IDMS-L@LISTSERV=2EIUASSN=2ECOM=0D=0ASent=
: Tue, 21 Sep 2010 14:19:40 -0000 (UTC)=0D=0ASubject: Re: question on QUED=
=0D=0A=0D=0AChris,=0D=0A=0D=0AMy guess is that QUED filled Journal (Say J1)=
and the COMT/ENDJ =0D=0Ais written to J2=2E So first condense of J1 will k=
eep the BFOR =0D=0Aimages for QUED=2E The next condense should get rid of t=
hem=2E=0D=0A=0D=0AHTH=0D=0A=0D=0APete=0D=0A=0D=0A-----Original Message-----=
=0D=0AFrom: IDMS Public Discussion Forum =0D=0A[mailTo:IDMS-L@LISTSERV=2EIU=
ASSN=2ECOM] On Behalf Of Chris Hoelscher=0D=0ASent: 21 September 2010 14:48=
=0D=0ATo: IDMS-L@LISTSERV=2EIUASSN=2ECOM=0D=0ASubject: question on QUED=0D=
=0A=0D=0Ai have a very active read-only CV - however it does update =0D=0AQ=
ueues (being r/o journals are very small)=0D=0A=0D=0Aalthough several appli=
cations have been subset - the jobs that =0D=0Awrite to these queues are st=
ill active- so i execute QUED =0D=0Aprompt I note then when a journal fills=
and the info message is written=0D=0A=0D=0ADC205030 V75 T53649733 LID=3D41=
79105942 PROG=3DRHDCRUAL =0D=0ASUBS=3DIDMSNWK7 BFOR=3D438KB=0D=0A=0D=0Arhd=
crual is the program - interestingly - even though i exit =0D=0Aqued - cond=
ensing does not free up the journal space=0D=0A=0D=0Ais this because a pre-=
defined (RHDCRUAL) run unit is considered =0D=0Astill active and as such th=
e BFORS cannot be removed?=0D=0A=0D=0Athe DCMT D RUNUNIT shows:=0D=0A=0D=0A=
TYPE QUEUE=0D=0A =
DRIVER TASK ID 0000000002=0D=0A SUBSCHEMA I=
DMSNWK7=0D=0A NODE=0D=0A =
DICTNAME/DBNAME SYSTEM=0D=0A IDLE INTERVAL OF=
F=0D=0A PREDEFINED RUN UNITS 2=0D=0A RUN UNIT AL=
LOCATIONS 162=0D=0A RUN UNIT FREES 162=0D=
=0A OVERFLOW RUN UNITS 0=0D=0A =
AREA NAME DDLDCRUN=0D=0A USAGE MODE SHARE=
D UPDATE=0D=0ATYPE BOUND IN-USE ALLOCS OWNING TASK=0D=0APERM YES =
NO 161=0D=0APERM YES NO 1=
=0D=0A=0D=0A=0D=0AChris Hoelscher=0D=0AIDMS/DB2 System & Database Architect=
=0D=0AHumana Inc=0D=0A502-476-2538=0D=0Achoelscher@humana=2Ecom=0D=0A=0D=0A=
I refuse to repeat gossip - so listen carefully the first time=0D=0A=0D=0A=
=0D=0A=0D=0A=0D=0AThe information transmitted is intended only for the pers=
on or =0D=0Aentity to which it is addressed and may contain CONFIDENTIAL =
=0D=0Amaterial=2E If you receive this material/information in error, =0D=
=0Aplease contact the sender and delete or destroy the =0D=0Amaterial/infor=
mation=2E=0D=0AThis e-mail may contain confidential or privileged informati=
on=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=0AT=
hank you=2E Aetna
"
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: question on QUED
"SSBhZ3JlZSB3aXRoIERvbi4NCg0KV2UgdXNlIFJIRENSVUFMIHJ1biB1bml0cyBhbGwgdGhlIHRp
bWUgd2l0aCBubyBwcm9ibGVtcyAoc2VlIGJlbG93KS4NCkJ1dCB3ZSBoYXZlIGhhZCBwcm9ibGVt
cyB3aXRoIFFVRUQgYmVpbmcgYSByZXNvdXJjZSBob2cuICBJZiB5b3VyIGpvdXJuYWxzIGFyZSB2
ZXJ5IHNtYWxsLCB0aGF0IGNvdWxkIGJlIG9uZSBvZiB0aGUgcmVzb3VyY2VzIHRoYXQgeW91IHJ1
biBvdXQgb2YuDQoNCiAgICAgICAgICAgICAgICAgICAgIFRZUEUgUVVFVUUgICAgICAgICAgICAg
ICANCiAgICAgICAgICAgRFJJVkVSIFRBU0sgSUQgMDAwMDAwMDAwMiAgICAgICAgICANCiAgICAg
ICAgICAgICAgICBTVUJTQ0hFTUEgSURNU05XSzcgICAgICAgICAgICANCiAgICAgICAgICAgICAg
ICAgICAgIE5PREUgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICBESUNUTkFNRS9EQk5B
TUUgU1lTVEVNICAgICAgICAgICAgICANCiAgICAgICAgICAgIElETEUgSU5URVJWQUwgT0ZGICAg
ICAgICAgICAgICAgICANCiAgICAgUFJFREVGSU5FRCBSVU4gVU5JVFMgICAgICAgICAzICAgICAg
ICAgICANCiAgICAgUlVOIFVOSVQgQUxMT0NBVElPTlMgICAgMTU4ODkyICAgICAgICAgICANCiAg
ICAgICAgICAgUlVOIFVOSVQgRlJFRVMgICAgMTU4ODkyICAgICAgICAgICANCiAgICAgICBPVkVS
RkxPVyBSVU4gVU5JVFMgICAgICAgICAxICAgICAgICAgICANCiAgICAgICAgICAgICAgICBBUkVB
IE5BTUUgRERMRENSVU4gICAgICAgICAgICANCiAgICAgICAgICAgICAgIFVTQUdFIE1PREUgU0hB
UkVEIFVQREFURSAgICAgICANClRZUEUgIEJPVU5EICBJTi1VU0UgICAgQUxMT0NTICAgT1dOSU5H
IFRBU0sgICANClBFUk0gICBZRVMgICAgTk8gICAgICAgIDE1NzgxNSAgICAgICAgICAgICAgICAN
ClBFUk0gICBZRVMgICAgTk8gICAgICAgICAgMTA2OCAgICAgICAgICAgICAgICANClBFUk0gICBZ
RVMgICAgTk8gICAgICAgICAgICAgOCAgICAgICAgICAgICAgICANCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSURNUyBQdWJsaWMgRGlzY3Vzc2lvbiBGb3J1bSBbbWFpbHRv
OklETVMtTEBMSVNUU0VSVi5JVUFTU04uQ09NXSBPbiBCZWhhbGYgT2YgZG9uamNhc2V5QENPTUNB
U1QuTkVUDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTAgOToyMiBBTQ0KVG86IElE
TVMtTEBMSVNUU0VSVi5JVUFTU04uQ09NDQpTdWJqZWN0OiBSZTogcXVlc3Rpb24gb24gUVVFRA0K
DQpJIHRoaW5rIHlvdXIgcHJvYmxlbSBpcyB0aGF0IHRoZSBRVUVEIHRhc2sgd2FzIHVuYWJsZSB0
byB3cml0ZSBhbiBBQlJUIGNoZWNrcG9pbnQgcmVjb3JkLCBzbyB3YXMgdW5hYmxlIHRvIHJvbGxi
YWNrLg0KDQpUaGUgIm5vcm1hbCIgUkhEQ1JVQUwgcnVuIHVuaXRzIHNob3VsZCBiZWhhdmUgc2lt
aWxhciB0byBhbnkgb3RoZXIgcnVuIHVuaXQgdGhhdCB0YWtlcyBhIENPTU1JVCwgbG9ja3MgYXJl
IGZyZWVkIGFuZCBqb3VybmFsIGltYWdlcyBhcmUgYXZhaWxhYmxlIGZvciBvZmZsb2FkaW5nLg0K
DQpJbiB0aGUgY2FzZSBvZiBRVUVELCBpdCAoZXZpZGVudGx5KSB0YWtlcyBubyBDT01NSVRzLCBz
byB1bmxlc3MgeW91IGNhbiBob2xkIGFsbCB0aGUgQkZPUi9BRlRSIGltYWdlcyBpbiB5b3VyIGpv
dXJuYWxzLCB5b3UnbGwgZXhoYXVzdCBhbGwgeW91ciBqb3VybmFscy4NCg0KSnVzdCBhIGh5cG90
aGVzaXMuDQoNCkRvbiBDYXNleQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9t
OiBDaHJpcyBIb2Vsc2NoZXIgPGNob2Vsc2NoZXJASFVNQU5BLkNPTT4NClRvOiBJRE1TLUxATElT
VFNFUlYuSVVBU1NOLkNPTQ0KU2VudDogVHVlLCAyMSBTZXAgMjAxMCAxMzo0Nzo0MiAtMDAwMCAo
VVRDKQ0KU3ViamVjdDogcXVlc3Rpb24gb24gUVVFRA0KDQppIGhhdmUgYSB2ZXJ5IGFjdGl2ZSBy
ZWFkLW9ubHkgQ1YgLSBob3dldmVyIGl0IGRvZXMgdXBkYXRlIFF1ZXVlcyAoYmVpbmcNCnIvbyBq
b3VybmFscyBhcmUgdmVyeSBzbWFsbCkNCg0KYWx0aG91Z2ggc2V2ZXJhbCBhcHBsaWNhdGlvbnMg
aGF2ZSBiZWVuIHN1YnNldCAtIHRoZSBqb2JzIHRoYXQgd3JpdGUgdG8NCnRoZXNlIHF1ZXVlcyBh
cmUgc3RpbGwgYWN0aXZlLSBzbyBpIGV4ZWN1dGUgUVVFRCBwcm9tcHQNCkkgbm90ZSB0aGVuIHdo
ZW4gYSBqb3VybmFsIGZpbGxzIGFuZCB0aGUgaW5mbyBtZXNzYWdlIGlzIHdyaXR0ZW4NCg0KREMy
MDUwMzAgVjc1IFQ1MzY0OTczMyBMSUQ9NDE3OTEwNTk0MiAgUFJPRz1SSERDUlVBTCBTVUJTPUlE
TVNOV0s3DQpCRk9SPTQzOEtCDQoNCnJoZGNydWFsIGlzIHRoZSBwcm9ncmFtIC0gaW50ZXJlc3Rp
bmdseSAtIGV2ZW4gdGhvdWdoIGkgZXhpdCBxdWVkIC0NCmNvbmRlbnNpbmcgZG9lcyBub3QgZnJl
ZSB1cCB0aGUgam91cm5hbCBzcGFjZQ0KDQppcyB0aGlzIGJlY2F1c2UgYSBwcmUtZGVmaW5lZCAo
UkhEQ1JVQUwpIHJ1biB1bml0IGlzIGNvbnNpZGVyZWQgc3RpbGwNCmFjdGl2ZSBhbmQgYXMgc3Vj
aCB0aGUgQkZPUlMgY2Fubm90IGJlIHJlbW92ZWQ/DQoNCnRoZSBEQ01UIEQgUlVOVU5JVCBzaG93
czoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUWVBFIFFVRVVF
DQogICAgICAgICAgICAgICAgICAgRFJJVkVSIFRBU0sgSUQgMDAwMDAwMDAwMg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBTVUJTQ0hFTUEgSURNU05XSzcNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgTk9ERQ0KICAgICAgICAgICAgICAgICAgRElDVE5B
TUUvREJOQU1FIFNZU1RFTQ0KICAgICAgICAgICAgICAgICAgICAgICAgSURMRSBJTlRFUlZBTCBP
RkYNCiAgICAgICAgIFBSRURFRklORUQgUlVOIFVOSVRTICAgICAgICAgICAgMg0KICAgICAgICAg
UlVOIFVOSVQgQUxMT0NBVElPTlMgICAgICAxNjINCiAgICAgICAgICAgICAgICAgICBSVU4gVU5J
VCBGUkVFUyAgICAgICAgICAxNjINCiAgICAgICAgICAgT1ZFUkZMT1cgUlVOIFVOSVRTICAgICAg
ICAgICAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUkVBIE5BTUUgRERMRENS
VU4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFVTQUdFIE1PREUgU0hBUkVEIFVQREFURQ0K
VFlQRSAgQk9VTkQgIElOLVVTRSAgICAgQUxMT0NTICAgT1dOSU5HIFRBU0sNClBFUk0gICBZRVMg
ICAgICBOTyAgICAgICAgICAgICAgICAgMTYxDQpQRVJNICAgWUVTICAgICAgTk8gICAgICAgICAg
ICAgICAgICAgICAgIDENCg0KDQpDaHJpcyBIb2Vsc2NoZXINCklETVMvREIyIFN5c3RlbSAmIERh
dGFiYXNlIEFyY2hpdGVjdA0KSHVtYW5hIEluYw0KNTAyLTQ3Ni0yNTM4DQpjaG9lbHNjaGVyQGh1
bWFuYS5jb20NCg0KSSByZWZ1c2UgdG8gcmVwZWF0IGdvc3NpcCAtIHNvIGxpc3RlbiBjYXJlZnVs
bHkgdGhlIGZpcnN0IHRpbWUNCg0KDQoNCg0KVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlz
IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk
ZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gQ09ORklERU5USUFMIG1hdGVyaWFsLiAgSWYgeW91IHJl
Y2VpdmUgdGhpcyBtYXRlcmlhbC9pbmZvcm1hdGlvbiBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3Qg
dGhlIHNlbmRlciBhbmQgZGVsZXRlIG9yIGRlc3Ryb3kgdGhlIG1hdGVyaWFsL2luZm9ybWF0aW9u
Lg0K
"
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: question on QUED
"Where do all these BFOR images come from that you're referring to? QUED reads a record, deletes a record, maybe. At most there are two images. At best, only one BFOR image per record read. It's a sequential sweep, so no repetition of records read. So there is nothing to condense. No?

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

Outcomes