MainframeSupports
tip uge 13/2000:

Når man kalder et CSP-program fra et COBOL BATCH-program, så vil CSP etablere sit runtime-miljø. Når CSP-programmet terminerer, vil det fjerne runtime-miljøet igen. Hvis man laver mange kald til samme CSP-program eller til forskellige CSP-programmer, så vil CSP runtime-miljøet blive etableret og fjernet igen et utal af gange og det er faktisk rigtig ressourcekrævende.

Der er rundt omkring i forskellige installationer, hvor man benytter CSP gjort forskellige tiltag for at imødegå dette problem. Nogle har forbudt brugen af CSP i BATCH. Andre har etableret snedige såkaldte pre-load værktøjer, hvor man på forskellig måde forsøger at etablere CSP runtime-miljøet i forvejen.

Der findes faktisk en simpel løsning på problemet. Man laver et CSP-program, hvis eneste funktion det er at kalde COBOL-programmet. Vupti, nu etableres CSP runtime-miljøet først, og det vil således være på plads for alle de CSP-programmer, der kaldes fra COBOL-programmet. Resultatet vil selvfølgelig være afhængigt af antallet af kald til CSP-programmer fra COBOL-programmet, men jeg har set reduktioner af køretiden på op imod 80-90%.

For den fingernemme programmør vil det være forholdsvis let at lave et CSP-program, der kan starte et hvilket som helst COBOL-program med bevarelse af input fra PARM-parameteren i JCL. Så behøver man ikke at lave et CSP-program for hvert COBOL-program, man vil optimere.

Man skal være opmærksom på en ting, som kan drille ret alvorligt. Hvis de kaldte CSP-programmer bruger DB2-cursore, og disse ikke bliver lukket inden CSP-programmet afsluttes, så kan det medføre de mærkeligste fejl. Problemt opstår, når man kalder det samme CSP-program igen, og det kaldende COBOL-program imellem de to kald udsteder en COMMIT (eller ROLLBACK). COMMIT lukker alle åbne cursore, men CSP runtime-miljøet tror stadig at cursoren i CSP-programmet er åben. Grunden til, at denne fejl pludselig opstår skyldes, at før optimeringen var CSP runtime-miljøet jo ikke "i live" mellem de to kald, så derfor ville det ikke vide noget om nogen cursore, der ikke var blevet lukket.

Sidste uges tip        Tip oversigten