ISPF EDIT/VIEW kommandoen CHANGE har en indbygget indrykningsalgoritme, som de færreste af os tænker over, når vi laver en CHANGE <source> <target>, hvor <target> indeholder flere tegn end <source>. I denne situation er EDIT nødt til at rykke tegnene til højre for <source> det antal tegn <target> er længere end <source> til højre. Det er OK at tygge lidt på forrige sætning. Jeg kan ikke formulere det bedre.
Hvis EDIT mener, at CHANGE-kommandoen kun kan gennemføres ved at skubbe ikke-blanke tegn yderst til højre i en linie/record ud over kanten, så markeres linien med ERR i line-command arealet og ændringen gennemføres ikke i den pågældende linie. Hvis der et eller andet sted til højre for <source> optræder to eller flere blanke tegn efter hinanden, så reduceres de til et mindre antal blanke afhængig af hvor meget længere <target> er i forhold til <source>. Dette er en udmærket algoritme i langt de fleste tilfælde og sandsynligvis grunden til, at man sjældent tænker over, at det er sådan EDIT udfører CHANGE-kommandoen.
Forleden havde jeg behov for at lave en change af & til &&, fordi && af et værktøj blev oversat til &, mens & af det pågældende værktøj blev fortolket som starten på en symbolsk variabel (ligesom i JCL og CLIST). Mit problem var bare, at positionerne af data efter en & gerne skulle passe, når værktøjet erstattede && med &. Det skete jo desværre ikke, når der var to eller flere sammenhængende blanke et eller andet sted til højre for den første &. Her vil et eksempel til at afsløre problemstillingen være på sin plads:
Men det, jeg i virkeligheden ønskede mig, var:
Efter lidt granskning af ISPF EDIT/VIEW manualen gik det op for mig, at der tilsyneladende ikke er en option, der slår den normale indrykningsalgoritme fra, så CHANGE rykker alt til højre lige meget. Så hvad skulle jeg så lige gøre. Løsningen var følgende:
Grunden til, at jeg valgte x'FA' til at erstatte blanke tegn var, at dette tegn ikke optrådte i de data, jeg editerede. Hvis alle tegn i data er display-bare, så kan x'00' fint anvendes. I mit tilfælde var record-længden 80, så jeg valgte at udskifte de sidste 8 tegn med blanke. Husk altid at udskifte de sidste x tegn med blanke. Fremgangsmåden kræver også, at alle linier/records slutter med et antal blanke tegn. Hvis ikke, så virker min fremgangsmåde ikke efter hensigten. Hvis de data, du opererer med kommer fra et VB dataset og du kører med PRESERVE ON, så vil fremgangsmåden også lide skibbrud, da resultatet af ovenstående vil blive, at samtlige records vil have fuld længde, og det var måske ikke lige, hvad du ønskede dig. Hvis du derimod bruger PRESERVE OFF, så virker det fint, bortset fra de records, der ikke slutter med tilstrækkelig mange blanke.
Hvis du har været ude for samme problemstilling som ovenfor og fandt en mere elegant løsning, så hører jeg meget gerne fra dig. Især hvis du ved, hvordan man kan få EDIT til at slå den normale indrykningsalgoritme fra.