read vs lock

kasus ini gw temuin kemaren.

pada awalnya gw bingung knapa tabel ini ke lock. padahal di mesin yang satunya ga ada masalah untuk proses yang sama, data yang sama, dan program dari source yang sama.

solusi pertama yang gw dapet adalah dengan men-delay job utama sbelum mengupdate nilai, ketika sluruh job yang dia buat telah slesai melakukan tugasnya. ini dilakukan tuk ngeyakinin bahwa job telah me-release table sehingga bisa di update sama job utama. ternyata ini bukan solusi. tabel masih di lock. hmmm…

solusi kedua. suspect ternyata bukan job yang dibuat, tapi si job utama yang nge-lock. code gw review lagi. then, ok di CL programnya gw kasih command OVRDBF FILE(namaFileDb) SHARE(*YES) sbelum manggil RPGLE-nya dan DLTOVR FILE(namaFileDb) setelahnya. command ini berfungsi untuk mengoveride file dan membuat file tsb share for update untuk program lain -yang juga akan menggunakan file tsb- ktika dibuka oleh programnya. then, compile, run….. LCKW (lock wait)…. MSGW(mesej wait-pertanda program mental/error)… anjrit, masih nge-lock. dah stengah hari lebih nih. hmmm…

solusi ketiga. review lagi code job utama… review lagi code program yg di panggil oleh job yang dibuat job utama… telaah lagi CPF (error information) dari MSGW yang muncul… nah dapet juga jawabannya. job yang dibuat job utama ga bisa dapetin record yang akan di update karena di-lock oleh job utama tabel PF nya. padahal yang dipake job yang dibuat adalah LF nya. yo wes, gw OVRDBF aja nih LF. ini juga saran dari temen gw -juga trainer RPG gw, Pak Ardijan-. then, compile…. shalat magrib dulu…. run…. LCKW…. MSGW….(again? arghhh..)

solusi keempat. review lagi…liat MSGW nya lagi… dan… gw baru nyadar ada tulisan “can not alocate object at line xxx (gw lupa), because it’s being used by another program” kurang lebih seperti itu lah. gw liat compile-an code nya. ternyata line tersebut adalah opcode CHAIN ke LF. karena job brjalan paralel gw cek kmungkinan job utama lagi ngapain pas job yg dibuatnya nge-CHAIN. owch…lagi loop tuk opcode READ tabel PF yang LF nya di-CHAIN job yg dibuat. ini lock nya level record brarti, solusi dua dan tiga tuh untuk lock level tabel. kok READ nge-lock ya??? setau gw slama ini, meskipun file spec nya UF (bisa read, update) atau UF A (bisa read, update, insert) untuk READ baik diawali opcode KEY SETLL atau ga, ga akan nge-lock. gw simulasiin, gw bikin 2 program kecil. dan hasilnya bener ngelock. akhirnya gw kasih (N). opcode jadinya READ (N) -pada kolom (E)- klo di RPG. klo di RPGILE bisa langsung READ(N). penambahan (N) ini mengakibatkan record tidak di-lock tapi hanya di read saja. (N) ini bisa dipake juga untuk opcode READP, READE, CHAIN. Soalnya untuk file spec UF atau UF A baik READ, READE, READP ataupun CHAIN, dia akan nge-lock record. gw simulasiin….dan….sukses. gam nge-lock lg. solusi ini hasil diskusi dengan dicky. tinggal compile nih… hmmm… mba erna nya dah pulang (jam brapa ini bung???, stengah smbilan!!!), besok aja deh jadinya. -besok paginya- compile… run… pass… ok sip. dah bener akhirnya. delay dicabut lg, tp OVRDBF tetep dipake.

INGAT, klo pake file spec UF atau UF A harus pake (N) untuk tujuan read doang. tapi klo buat update, ya ga usah. karena emang harus di-lock.
hanya file spec IF yang ga nge-lock ktika pake opcode CHAIN, READ, READP, READE.