Cobol bild klausul binära alternativ

Söka och sökordet Vi har sett hur vi kodar en egen bordssökning, nu ska vi titta på ett alternativ, sökordet SÖK. SÖK-verb automatiserar sökprocessen och är användbar i en stor andel av tiden när du behöver göra en sökning. Innan vi faktiskt diskuterar sökordet, bör du granska och förstå logiken för en sökning. Det finns två typer av sökningar: LINEAR SEARCH och BINARY SEARCH. Båda kan kodas av programmeraren med hjälp av traditionell kod eller kodad av programmeraren med hjälp av SEARCH-verben. Sökningen som kodas av programmeraren med hjälp av traditionell kod använder en OCCURS för att definiera återkommande av elementen i tabellen och prenumerationen att styra steg genom bordet ett element åt gången med looping. Låt oss titta närmare på en prenumeration. En prenumeration är i huvudsak en pekare som pekar på ett av elementen i tabellen. Prenumerationen är ett traditionellt fält under programmerarens kontroll. Subskriptet initialiseras vanligen med ett MOVE-uttalande och ökas med ett ADD-meddelande (eller en SUBTRACT-rapport om prenumerationen minskades). Prenumerationen definieras av programmeraren. I motsats till prenumerationen använder SEARCH-verben ett index som definieras med namn med tabellen. Den faktiska inställningen av indexet görs via COBOL. Indexet är begränsat i bruk. Det måste användas med bordet som definierade det och det måste styras med antingen PERFORM-satsen med den varierande klausulen eller SET-verbet. I grunden har en programmerare mycket mer kontroll över manipuleringen av ett prenumeration än ett index. Eftersom indexet används med sökordet, definieras begränsningarna för att maximera den effektiva användningen i det sammanhanget. Linjär sökning: Den sökning som vi har tittat på är en linjär sökning. En linjär sökning kontrollerar fältet vi behöver matcha mot varje element i tabellen för att se om de matchar. Traditionellt börjar sökningen med det första elementet i bordet och slutar när en matchning hittas eller vi har kontrollerat varje post i tabellen. Det bör noteras att om elementen i tabellen är i ordning, kan en tidig utgång avkodas. Titta på soppexemplet är varunummerna i ordning. Om vi ​​letar efter en match till 18 behöver vi inte söka hela bordet, vi kan sluta titta när objektet i tabellen är större än det nummer vi letar efter. 18. Med andra ord, när sökningen jämför 18 till 24 i bordet kan vi förklara sökningen efter att vi har passerat den punkt där matchen skulle ha varit. Detta exempel på sökningen har en tidig utgång som görs genom att helt enkelt ändra PERFORM UNTIL. Ändringen har blivit markerad. Ta en liten stund för att granska den traditionella sökningen nedan och sedan går vi vidare till sökordet. Nu ska vi göra samma sökning med hjälp av SEARCH-verben. Först måste vi definiera tabellen. Skillnaden är att vi vid fastställandet av tabellen också upprättar indexet. Det linjära sökordet använder SET-satsen för att upprätta indexet före sökningen. SÖK-verbet är än vanligt för att utföra linjär sökning. Formatet för SET-satsen är: Det finns också ett speciellt format för att lägga till eller minska indexet: Formatet för det linjära SEARCH-verbet är: Med SEARCH-verbet kan sökningen efter en match i soppbordet vara: Things att notera: det namn som användes efter ordsökningen definierades med OCCURS-koden AT END används för att berätta vilken behandling som ska göras om sökningen inte lyckades - den här klausulen är valfri, så om ingen särskild behandling ska vara gjort om sökningen misslyckas än den här klausulen kan elimineras WHEN-klausulen jämför elementet i tabellen till det element som programmet försöker matcha - då behandlingen som ska göras om matchningen hittas är kodad Observera att i sökningen du Kod dig själv och SEARCH-verbet finns det några likheter. Båda initierar prenumerationen eller indexet innan sökningen startas. Båda har en jämförelseförklaring jämförande ett element i tabellen till det element som försöker matchas Båda tillåter bearbetning om matchen lyckas Båda tillåter behandling om matchen misslyckas Binär sökning: En binär sökning är en mycket effektiv sökning när du har att göra med ett stort bord. Observera att en binär sökning endast fungerar om bordet är i ordning av det element du söker. En binär sökning tittar på det första objektet i tabellen. Om en matchning hittas är sökningen klar. Om en match inte hittas kontrollerar den att se om objektet du försöker matcha är större eller mindre än mittelementet. Om det är större än vi vet att vi bara måste titta på halvan av bordet över mitten. Om det är mindre än vi vet att vi bara måste titta på halvan av bordet före mitten. Baserat på detta beslut har vi eliminerat hälften av bordet från sökningen. Vi tittar nu på mellannementet i halvdelen som är kvar och jämför det med elementet. Detta kommer antingen att hitta en match eller eliminera ett annat kvartal av tabellen. Observera att för att fastställa vad mitten är om antalet element är jämn kan programmeraren för en binär sökning välja att runda eller stympa. Denna process fortsätter tills en matchning hittas eller det är tydligt att elementet inte finns i tabellen. Titta på varunummerna i vårt soppexempel, skulle binärsökningen fortsätta på detta sätt för att hitta en match för nummer 27: ANVÄNDNINGSKlausul USAGE-klausulen anger formatet för en dataobjekt i datorminnet eller i en filrekord. Under vissa omständigheter kan ett filformatformat för dataposter skilja sig från dess datorminnesformat som anges av USAGE-klausulen. Detta kan inträffa när icke-COBOL-filsystem med olika datalagringsformat nås via ett gränssnitt. Acu4GL använder till exempel SQL för att få tillgång till icke-COBOL-filsystem, och i processen sker en översättning på data. Obs! Det finns många kompilatoralternativ för att påverka datalagringsbeteendet. Se Data Storage Options i avsnittet ACUCOBOL-GT Compatibility. Kolumnen till vänster visar de accepterade förkortningarna för villkoren till höger: En ANVÄNDNINGsklausul kan användas i vilken databeskrivning som helst, med undantag för de med nivånummer 66, 78 och 88. En användningsklausul får inte användas med en extern flytande punktdatapost. Om en USAGE-klausul finns i databeskrivning-posten för ett gruppobjekt, måste alla användningsklausuler som visas för underordnade poster vara av samma typ. PICTURE-strängen i en COMP, COMP-1, COMP-2, COMP-3, COMP-4, COMP-5, COMP-6, BINARY eller PACKED-DECIMAL-objektet kan bara innehålla symbolerna 9, S, V och P. COMP-6-objekt får inte använda S-symbolen. PICTURE-strängen i ett COMP-X - eller COMP-N-objekt kan innehålla endast alla 9 symboler eller alla X-symboler. Dataobjektet för en USAGE IS INDEX-dataobjekt kan inte innehålla någon av följande klausuler: BLANKNAD NÅR NOLL, RÄTT, BILD OCH VÄRDE ÄR. Nivå 88-poster kan inte anges för en USAGE IS INDEX-dataobjekt. Dataobjektet för en USAGE IS POINTER-dataobjekt kan inte innehålla någon av följande klausuler: BLANK NÄR, NED, RÄTT, eller BILD. En POINTER-dataobjekt kan ha en värdeklausul som anges för den, men värdet måste vara ordet NULL. Data beskrivning posten för en USAGE IS FLOAT eller en USAGE DOUBLE data-objekt kan inte innehålla någon av följande klausuler: BLANK NÄR, NED, RÄTT, eller BILD. FLOAT - eller DUBBEL-data kan ha en värdeklausul. Värdet kan vara en flytande punkt bokstavlig, en numerisk bokstavlig ord eller ordet NOLL. Här är ett exempel på dataobjektet Working-Storage Section: Följande kallas kollektivt datatyperna C-format: SIGNED-INT, UNSIGNED-INT, SIGNED-SHORT, UNSIGNED-SHORT, SIGNED-LONG, UNSIGNED-LONG. Dessa datatyper liknar de datatyper som finns på C-programmeringsspråket. Databeskrivningen för en C-typdatatyp kan inte innehålla någon av följande klausuler: BLANK NÄR, NED, RÄTT, eller BILD. Kontrolltyp är ett av de grafiska kontrolltypnamnen som är kända för kompilatorn, t. ex. LABEL eller ENTRY-FIELD, eller namnet på en ActiveX, COM eller Control. Datainnefattningsuppgifterna för ANVÄND HANDLE-data kan inte innehålla någon av följande klausuler: BLANK NÄR, NED, RÄTT, ELLER BILD. Om den innehåller en VALUE-klausul, måste det angivna värdet vara ordet NULL. Teckensnamn är en av följande identifierare: DEFAULT-FONT, FIXED-FONT, TRADITIONAL-FONT, SMALL-FONT, MEDIUM-FONT, LARGE-FONT. Det bör noteras att antingen - Df-alternativet eller - Cv-alternativet kommer att få kompilatorn att behandla COMP-1 och COMP-2 som FLOAT respektive DUBBEL. För mer information, se avsnitt 5.4 i Övergång till ACUCOBOL-GT. Layout-namn är namnet på en av systemets standard layout managers. För närvarande kan detta bara vara LM-RESIZE. En USAGE-klausul som skrivs på en gruppnivå gäller för varje elementärt objekt som är underordnad det gruppobjektet. Om ingen USAGE-klausul anges anges användningen av användningsvisning. Det interna formatet för ett USAGE IS DISPLAY-objekt är ASCII. Formatet för ett indexobjekt är 32-bitars signerat binärt. Dess storlek är alltid fyra och den har en rad värden från -2147483647 till 2147483647. När en kompileringsomkopplare används för kompatibilitet med versioner före 6.0.0 (-Z52 till exempel) är en indexartikel 16 bitars osignerad binär storlek är alltid två och den innehåller värden från 0 till 65535. Formatet för ett COMP-1-dataobjekt är 16-bitars signerat binärt. De lagliga värdena sträcker sig från -32767 till 32767. Dataelementets storlek är alltid två byte, och högorderens halva data lagras i den vänstra byte. PICTURE-strängen som beskriver objektet är irrelevant. Till skillnad från andra numeriska datatyper kommer ett storleksfel endast att uppstå i COMP-1, COMP-X eller COMP-N-dataobjektet när värdet överstiger objektets fysiska lagring (med andra ord antalet 9s i objekten BILD ignoreras när storleksfel bestäms). För COMP-2 (decimallagring) lagras varje siffra i en byte i decimalformat. Om värdet är undertecknat, tilldelas en extra efterföljande byte för tecknet. Lagringen av COMP-2 är identisk med ANVÄNDNINGSVIS med högbeställda fyra bitar borttagna från varje byte. För COMP-3 (förpackad decimal) lagras två siffror i varje byte. En ytterligare halva byte tilldelas för tecknet, även om värdet är osignerat. Tecknet är placerat i det högsta läget och dess värde är 0x0D för negativt. Alla andra värden behandlas som positiva (men se regel 18 nedan). Storleken på ett objekt (inklusive en för det underförstådda tecknet) delas av två för att komma fram till dess faktiska storlek (avrundningsfraktioner upp). Formatet för ett COMP-4-objekt är två-komplement binärt (värdet utan dess decimalpunkt). COMP-4-värdena lagras i maskinoberoende format. Detta format placerar den högsta ordningsdelen av värdet i det vänstra läget och följer ned till lågorderdelen i det högsta läget. Antalet byte som en dataobjekt upptar beror på antalet 9s i dess BILD och på närvaron av olika kompileringstider. Till exempel kan du bara inkludera mer än arton 9s om ditt program har sammanställts för 31-siffrigt stöd. Detta sammanfattas i följande tabell: Obs! Om två värden ges, gäller det mindre värdet för osignerade dataposter och det större värdet gäller för signerade dataobjekt. COMP-5 används främst för att kommunicera med externa program som förväntar sig infödd datalagring. Formatet för ett COMP-5-dataobjekt är identiskt med en COMP-4 dataobjekt, förutom att data lagras i maskinberoende format. Den lagras i en ordning som är naturlig för värdmaskinen. Exempelvis motsvarar ett PIC S9 (9) COMP-5-dataobjekt ett 32-bitars binärt ord på värddatorn, och ett PIC S9 (20) COMP-5-objekt motsvarar ett 64-bitars ord. Obs! Data som lagras i ett COMP-5-fält kan inte transporteras till andra maskiner eftersom olika maskiner har olika naturliga bytebeställningar. På många maskiner (68000, mest RISC) är COMP-5 identisk med COMP-4. På andra (80x86, VAX) är det samma med byte i omvänd ordning. En VALUE-klausul för en COMP-5-dataobjekt lagras i ett maskinoberoende format och justeras när det laddas in i dataobjektet. Detta säkerställer att värdet är samma från maskin till maskin. På aritmetiska och icke-aritmetiska butiker i COMP-5-artiklar, om trunkering krävs, avkortas ACUCOBOL-GT som standard i decimal till antalet siffror som anges i PICTURE-klausulen. Du kan använda alternativet --TruncANSI compiler för att tvinga trunkering i binär till kapaciteten för den tilldelade lagringen av COMP-5-objekt. - Dz och - noTruncoptions påverkar också trunkering. Se bok 1, avsnitt 2.1.9, alternativ för datalagring, för mer information. Nivå 01 och nivå 77 dataposter som COMP-5 synkroniseras automatiskt till en lämplig maskingräns, oavsett inställningar för kompileringstid. Detta gör det möjligt för dig att skicka dessa objekt säkert till C-subrutiner utan att behöva ta hand om dig själv med justering. Om COMP-5 används med en PIC X (n) datapost och tilldelas ett alfanumeriskt värde, är resultaten odefinierade. Till exempel får följande kodfragment NUM att ha ett odefinierat nummer och det resulterande värdet för den sista raden blir 100: En PIC X (n) dataobjekt som används med COMP-5 kan inte undertecknas. Formatet för ett COMP-6-objekt är identiskt med ett COMP-3-objekt, förutom att det är unsigned och inget utrymme är allokerat för tecknet. Om antalet siffror är udda, läggs en noll till vänster på siffran innan den är packad. Således finns det två decimalsiffror per byte, och objektets faktiska storlek bestäms genom att dividera dess PICTURE-storlek med två och avrundning. En COMP-X-dataobjekt måste beskrivas med en bildsträng som består av endast 9 eller bara X-symboler. I båda fallen behandlas dataposten som ett osignerat binärt heltal, med internt minne som liknar en COMP-4 dataobjekt. Om X-symboler används för att beskriva objektet, är antalet bitgrupper som tilldelats objektet detsamma som antalet X-symboler i bildsträngen. Om istället 9 symboler används, är det antal byte som är tilldelat det minsta antalet byte som krävs för att hålla ett antal av den storleken. Till exempel kommer en PIC 99 dataobjekt att tilldelas 1 byte en PIC 9 (9) dataobjekt kommer att tilldelas 4 byte. Oavsett antal 9 symboler i objektbildsträngen kan det maximala värdet som kan lagras i en COMP - X-objektet bestäms av antalet byte som tilldelats den (högst 18 siffror, eller högst 31 siffror om det 31-siffriga stödet är i kraft). Exempelvis kan ett COMP-X-objekt som består av 1 byte rymma ett antal siffror från 0 till 255. Ett 2-byte COMP-X-nummer kan hålla mellan 0 och 65535. Ett storleksfel uppstår endast på ett COMP-X-objekt när värdet är större än dataobjektet kan innehålla fysiskt. När COMP-X används med en PIC (X) dataobjekt, är maximum PIC X (8). (Detta maximinivå ökar till PIC X (16) när det 31-siffriga stödet är i kraft.) Ett COMP-N-dataobjekt är identiskt med ett COMP-X-dataobjekt, förutom att data lagras i värddatorns inbyggda format, istället för maskinoberoende format. Dataposter som beskrivs som PACKED-DECIMAL är identiska med COMP-3. Du kan orsaka att unsigned PACKED-DECIMAL ska behandlas som COMP-6 med hjälp av ett kompileringsalternativ. Som standard är ett BINARY-dataobjekt identiskt med en COMP-4-dataobjekt. Kompileringstid - alternativet - D5 behandlar BINARY-dataobjekt som COMP-5-objekt i stället. I VAXCOBOL-kompatibilitetsläge är ett COMP-dataobjekt samma som COMP-4 och behandlas som binär data. I RMCOBOL-kompatibilitetsläget är COMP samma som COMP-2. Du kan använda kompileringstidsalternativ för att ändra standardbeteendet. En pekerdatapost behandlas som ett osignerat numeriskt dataobjekt. Det interna formatet skiljer sig åt för varje maskin. Pointerdata är avsedda att innehålla adresser till andra dataobjekt (se SET-stämningen.) En pekardatapost kan ha en VALUE-klausul som anges för den, men det angivna värdet måste vara ordet NULL. Detta indikerar att pekaren inte pekar på något objekt för närvarande. Om en pekare inte uttryckligen ges ett initialvärde, är dess initialvärde godtyckligt. Pointerdataobjekt upptar 8 byte. Detta ger tillräckligt med utrymme för att hålla en adress på en 64-bitars maskin. Om du befinner dig på en mindre maskin använder körtiden endast de första 4 byte av pekardataposter (de efterföljande 4 byte förblir i minnet, de är bara kvar oanvända). Du kan använda alternativet - Dw kompileringstid för att justera det utrymme som tilldelats pekardataposter. Du kan göra detta för att spara lagring om du vet att du inte kommer att köras på en 64-bitars maskin. Pekare kan användas i villkorliga uttryck, där de kan jämföras med varandra eller till värdet NULL. En jämförelse med en pekare måste vara lika med eller inte lika (större och mindre än jämförelser är inte tillåtna). Nivå 01 och nivå 77 dataobjekt som är POINTER-objekt synkroniseras automatiskt till en lämplig maskingräns, oavsett inställningar för kompileringstid. Detta gör det möjligt för dig att skicka dessa objekt säkert till C-subrutiner utan att behöva ta hand om dig själv med justering. Bortsett från den automatiska synkroniseringen behandlas dataobjektdata i alla avseenden som USAGE UNSIGNED-LONG dataposter. Detta hanterar alla aktuella maskiner korrekt. Detta beteende kan ändras för att uppfylla kraven för en framtida maskin. Flyttpunktsdataposter lagras i maskinberoende format. ANVÄNDNING FLOAT-objekt har 4 byte tilldelade dem. ANVÄNDNING DOUBLE-objekt upptar 8 byte. Värk 01 och nivå 77 dataposter som är USAGE FLOAT eller DOUBLE synkroniseras automatiskt till lämpliga maskingränser, oavsett inställningar för kompileringstid. Detta gör det möjligt för dig att skicka dessa objekt säkert till C-subrutiner utan att behöva ta hand om dig själv med justering. ANSI-definitionen av COBOL anger inte hur tecken ska lagras i numeriska fält (förutom för SIGN IS SEPARATE). ACUCOBOL-GT kan du välja alternativa signallagringskonventioner med hjälp av kompileringstidalternativen - Dca, - Dcb, - Dci, - Dcm, - Dcn, - Dcr och - Dcv. Att ange en konvention om signallagring är ibland användbar när du exporterar och importerar data. Mer information finns i Användarhandboken, avsnitt 2.2.10, Data Lagringsalternativ. Lagringskonventionen påverkar hur data visas i ANVÄNDNINGS DISPLAY, COMP-2 och COMP-3 datatyper. I USAGE DISPLAY, standard ASCII-lagring, om tecknet är införlivat i en siffraposition, kodas siffran enligt följande tabell: Tabellposter markerade med en asterisk anger objekt i fast storlek. En fast storlek är lika stor oavsett målmaskinen. Inlägg utan en asterisk är varierande i storlek. Dessa objekt kommer att rymma upp till det antal byte som anges i tabellen. Obs! De storlekar som anges i tabellen ovan täcker alla aktuella och förväntade maskiner som kör ACUCOBOL-GT. Framtida arkitekturer kan kräva ändringar av den maximala storleken som tilldelats dessa objekt. I exekveringsmiljön fungerar dessa saker på alla sätt som om de var korrekta dataposter av lämplig storlek. Till exempel kommer följande kodfragment: skriva ut 4 när det körs på en 32-bitars maskin, men den kommer att skriva ut 8 när den körs på en 64-bitars maskin. I följande exempel representeras varje byte av två hexadecimala siffror eller av en enda citerad tecken. Varje värde visas i olika format. Också visas användarguide med de olika SIGN-alternativen. Följande exempel använder standardkonventionerna för ACUCOBOL-GT-signallagring. HANDLE-dataposter utgör sin egen dataklass och kategori i COBOL. Internt lagras de som heltal, och uppför sig som nummer när de används. Ett HANDLE-dataobjekt används normalt för att lagra handtaget för ett dynamiskt skapat objekt, t. ex. ett flytande fönster eller en grafisk kontroll. HANDLE-dataobjekten finns i två former: typad och generisk. Du skapar ett generiskt handtag när du släpper fra frasen. Du skapar ett skrivet handtag när du inkluderar OF-frasen. Du får endast använda HANDLE-dataobjekt när det uttryckligen är tillåtet, eller som en del av ett MOVE-uttalande, ett CALL-uttalande (som en parameter) eller i ett booleskt uttryck. Generiska handtag kan användas i alla situationer där handtag är tillåtna. När du använder ett generiskt handtag som källa till ett MODIFY-uttalande, kommer du inte att kunna använda några kontrollspecifika egenskaper eller stilnamn i det uttalandet. Detta beror på att det generiska handtaget kunde associeras med någon typ av kontroll. I det här fallet kan kompilatorn inte bestämma vilken uppsättning stil - och egenskapsnamn som är giltiga. Typade handtag kan användas i uttalanden där något handtag är tillåtet, eller när du hänvisar till ett objekt av en matchande typ. Exempelvis kan en HANDLE OF WINDOW inte användas som handtaget i ett DISPLAY LABEL-meddelande. Istället måste du använda antingen ett generiskt handtag eller en etiketthandtag. Med typhandtag kan kompilatorn känna igen associerade stil - och fastighetsnamn när det är lämpligt. Typade handtag förbättrar också läsbarheten för ditt program genom att ge ytterligare information om den avsedda användningen av handtaget, förutom att du tillhandahåller kompileringstiden för att se till att du använder handtagen i lämpliga situationer. Handtag kan användas i jämförelser. Det finns bara två meningsfulla jämförelser: kontroll av jämlikhet eller ojämlikhet till NULL, och jämförelse med annan handtagsdata. Ett handtagsvärde på NULL anger alltid ett ogiltigt handtag. Handtag lagras internt som 4-byte binära heltal. Den här informationen kan vara användbar när du felsöker ett program (du kan undersöka värdena på handtag i felsökaren). Du borde dock inte lita på den här definitionen i ditt program, eftersom det kan komma att ändras i framtiden. Hantera dataobjekt synkroniseras automatiskt på en 4-bytegräns. Observera att detta inträffar oberoende av inställningen för alternativet - Dl kompileringstid (vilket begränsar synkroniseringsgraden). Runtime-systemet kräver denna nivå för anpassning för att undvika att skapa bussfel på vissa maskiner. Om teckensnamn specificeras, initieras dataposten som beskrivs av USAGE-klausulen vid programstart med motsvarande typsnittshandtag. Detta fungerar identiskt med att placera uttalandet: i början av ditt program, där data-objektet är dataobjektet som beskrivs av USAGE-klausulen och teckensnamn är detsamma som teckensnamn i USAGE-klausulen. Den interna representationen av data kan vara ett viktigt övervägande för program effektivitet. Tyvärr kan standardrepresentationen som används av COBOL för numeriska dataobjekt negativt påverka beräkningshastigheten. Ett effektivare format för numeriska data kan specificeras med hjälp av USAGE-klausulen. Denna enhet introducerar begreppet interna datapresentationer, det diskuterar standardrepresentationen som används i COBOL och beskriver hur den representationen, som används för numeriska data, kan orsaka ineffektivitet. Syntaxen för USAGE-klausulen ges och de olika alternativen förklaras. SYNCHRONIZED-klausulen införs och ett generellt exempel ges. Mål I slutet av den här enheten borde du: - Veta att text lagras i en dator med någon kodningssekvens. Förstå problemen som orsakas av att lagra numeriska data som ASCII-siffror. Använda använd användningsklausulen för att ändra hur numeriska data lagras i datorn. Känn när och hur man använder SYNCHRONIZED-klausulen. Förutsättningar Introduktion till COBOL Deklarera data i COBOL Grundläggande procedur Divisionskommandon Urval i COBOL Iteration i COBOL Introduktion till sekventiella filer Bearbetning Sekventiella filer Läser sekventiella filer Redigerade bilder Datorer lagrar sina data i form av binära siffror. Bortsett från kardinalen (positiva heltal) använder alla andra data som lagras i datorminnet en formateringskonvention. Textdata lagras till exempel med en kodningssekvens som ASCII eller EBCDIC. Ett kodningssystem är helt enkelt en konvention som anger att en viss uppsättning bitar ska användas för att representera en viss karaktär. Exempelvis visar diagrammet nedan den bitkonfiguration som används för att representera ett övre fall quotAquot i ASCII - och EBCDIC-kodningssekvenserna. Numeriska data kan hållas som textfigurer (ASCII-siffror) eller som rena binära nummer (i händelse av kardinala värden) eller som två komplement binära tal (i heltal) eller som decimaltal (med BCD), eller som reella tal (med ett riktigt nummerformat som IEEE-specifikationen för flytpunkter). USAGE-klausulen används för att ange hur ett dataobjekt ska lagras i datorminnet. Varje variabel som deklareras i ett COBOL-program har en USAGE-klausul - även om ingen uttrycklig klausul anges. När det inte finns någon explicit USAGE-klausul, används standardvärdet - ANVÄNDNING IS DISPLAY -. Problem med användningen är att visa hastigheten på moderna datorer innebär att det knappast är värt att försöka använda USAGE-klausulen om inte dataelementet kommer att användas i tusentals beräkningar. Av bärbarhetsskäl bör användningsbestämmelsen aldrig användas i rekordbeskrivningar. Om filen läses på ett annat datortillbehör, har vi ingen garanti för att uppgifterna tolkas korrekt. Även på samma tillverkare av dator, med användning av USAGE-klausulen i rekordbeskrivningar, betyder det att data i filen troligen inte kommer att förstås av andra programmeringsspråk eller av verktygsprogram eller av textredigerare. För textobjekt eller för numeriska objekt som inte ska användas i en beräkning (Kontonumre, Telefonnummer etc.), visar standardvärdet för USAGE IS DISPLAY inga problem, men för numeriska objekt som vissa beräkningar ska utföras på standardanvändning är inte det effektivaste sättet att lagra data. När numeriska objekt (PIC 9-objekt) har en användning av DISPLAY. De lagras som ASCII-siffror (se ASCII-siffrorna 0-9 i ASCII-tabellen nedan). Tänk på följande programfragment. Vad skulle hända om beräkningar gjordes direkt på nummer som lagrats i detta format Eftersom ingen av dataobjekten har en explicit USAGE-klausul, är de vanliga att - ANVÄNDNING ÄR DISPLAY. Det betyder att värdena i variablerna Num1, Num2 och Num3 lagras som ASCII-siffror. Hur gör dessa effektberäkningar Om du undersöker ASCII-tabellen nedan ser du att siffran 4 (värdet i Num1) kodas som 00110100 och siffran 1 är kodad som 00110001. När dessa dessa binära nummer läggs till tillsammans är resultatet 01100101 vilket är ASCII-koden för små bokstäver quotequot. Summan 4 1 e beräknar inte. När beräkningar görs med numeriska dataposter vars ANVÄNDNING VISAS, måste datorn omvandla de numeriska värdena till sina binära ekvivalenter innan beräkningen kan göras. När resultatet har beräknats måste datorn konvertera till ASCII-siffror. Omvandling till och från ASCII-siffror saktar ner beräkningarna. Därför deklareras ofta data som är mycket involverade i beräkningen med hjälp av en av de användningar som är optimerade för beräkning, såsom USAGE IS COMPUTATIONAL. Gruppobjekt behandlas alltid som alfanumerisk och det kan orsaka problem när det finns underordnad COMP-poster. Antag exempelvis att vi hade ett uttalande som - Flytta Zeros till Group2. i programmet motsatt. På ytan ser det ut som om detta uttalande rör det numeriska värdet 0 till NumItem1 och NumItem2 men det som faktiskt flyttas till dessa objekt är ASCII-siffran quot0quot. När ett försök görs att använda NumItem1 eller NumItem2 i en beräkning, kommer programmet att krascha eftersom dessa dataposter innehåller icke-numeriska data. USAGE-klausulen kan användas med vilken databeskrivning som helst, förutom de med nivånummer 66 eller 88. När användnings-klausulen förklaras för en gruppobjekt tillämpas den använda användningen på varje objekt i gruppen. Gruppobjektet behandlas fortfarande som ett alfanumeriskt dataobjekt (se exempelprogram nedan).USAGE COMPUTATIONAL eller COMP eller BINARY är synonymer till varandra. ANVÄNDNINGENS INDEX-klausul används för att ge ett optimerat tabellenabonnement. När ett bord är målet för ett SEARCH-uttalande måste det ha ett associerat indexobjekt (se sökhandledningen). Alla objekt som deklareras med ANVÄNDNINGSINDEX kan bara visas i: - En SÖK - eller SET-sats - Ett förhållandevillkor - ANVÄNDNINGSSÄTTNINGEN AV PROCEDURSDIVISIONEN - ANVÄNDNINGSSÄTTNINGEN I CALL-satsen Bildsträngen i ett COMP eller PACKED-DECIMAL-objekt kan innehåller bara symbolerna 9, S, V andor P. Bildklausulen som används för COMP eller PACKED-DECIMAL-objekt måste vara numerisk. 1QuadWord (8 Bytes) PACKED-DECIMAL Dataposter som anges som PACKED-DECIMAL hålls i binärkodad decimal (BCD) form. Istället för att representera värdet som ett enda binärt tal hålls binärvärdet för varje siffra i en nibble (en halv byte). Tecknet hålls i en separat nibble i objektets minst signifikanta position (se diagram nedan). Allmänna användningsanvisningar USAGE-klausulen är ett av de områden där många leverantörer har infört tillägg till COBOL-standarden. Det är inte ovanligt att se COMP-1. COMP-2. COMP-3. COMP-4. COMP-5 och POINTER-användningsposter i program som skrivs med dessa tillägg. Även om COMP-1 och COMP-2 är tillägg till COBOL-standarden, verkar leverantörer använda identiska representationer för dessa användningar. COMP-1 definieras vanligtvis som ett enda precision, flytpunktsnummer, som följer IEEE-specifikationen för sådana nummer (Real eller Float in typed languages) och COMP-2 definieras vanligtvis som ett dubbel precision, flytpunktsnummer (LongReal eller Double på typade språk). SYNCHRONIZED-klausulen SYNCHRONIZED-klausulen används ibland med USAGE IS COMP eller USAGE IS INDEX-objekt. Det används för att optimera bearbetningshastigheten men det gör det på bekostnad av ökade lagringskrav. Många datorminnen är organiserade på ett sådant sätt att det finns naturliga adressgränser - som ordgränser. Om inga speciella åtgärder vidtas kan vissa dataposter i minnet sträcka sig över dessa gränser. Detta kan orsaka en bearbetningskostnad eftersom CPU kan behöva två hämtningscykler för att hämta data från minnet. SYNCHRONIZED-klausulen används för att uttryckligen inrätta COMP och INDEX-objekt längs deras naturliga ordgränser. Utan SYNCHRONIZED-klausulen justeras dataposter på byte gränser. Ordet SYNC kan användas istället för SYNCHRONIZED. Effekten av den synkroniserade klausulen är implementeringsberoende. Du måste läsa din leverantörshandbok för att se hur det fungerar på din dator (i vissa fall kan det inte ha någon effekt). För att illustrera hur SYNCHRONIZED-klausulen fungerar, låt oss anta att ett COBOL-program körs på en ordorienterad dator där CPU hämtar data från minnet ett ord åt gången. I det här programmet vill vi utföra en beräkning på numret som lagras i variabeln TwoBytes (som deklareras i diagrammet nedan). På grund av hur dataobjekten har deklarerats, sträcker sig numret som lagras i TwoBytes ett ordgräns. För att kunna använda numret måste CPU exekvera två hämtningscykler - en för att få den första delen av numret i Word2 och den andra för att få den andra delen av numret i Word3. Denna dubbla hämtning saktar ner beräkningarna. Now consider the impact of using the SYNCHRONIZED clause. The number in TwoBytes is now aligned along the word boundary, so the CPU only has to do one fetch cycle to retrieve the number from memory. This speeds up processing but at the expense of wasting some storage (the second byte of Word2 is no longer used). Copyright Notice These COBOL course materials are the copyright property of Michael Coughlan. Alla rättigheter förbehållna. No part of these course materials may be reproduced in any form or by any means - graphic, electronic, mechanical, photocopying, printing, recording, taping or stored in an information storage and retrieval system - without the written permission of the author. (c) Michael Coughlan