I wrote a program using JMX API to calculate JVM Usage percentage. Code makes use of 2 attributes of java.lang:type=Memory MBean (used and max attribute).
When I use the formula (used/max * 100) to calculate JVM Used Memory Percent, it gives me very different value than what is displayed in JMC Software. For example:
In JMC I see the Percentage as 45.3%. But used = 708MB and max = 6GB, which in turn in my code gives very less percentile.
From Task Manager > Process Tab > Memory Column, I looked for the corresponding TomEE memory usage which is closed to the usage attribute in JMC.
Need some guidance here on what is the right way to calculate or look for the JVM Usage Percentage. Why there is a difference of percentage in JMC attribute (HeapMemoryUsagePercent) and the percentage calculation in my code?
I'm trying to report battery information for a battery-powered HID device (USB when plugged, BLE otherwise). Reading through the report descriptor from the example in Appendix A of Usage Tables for HID Power Devices (v1.1) I see two collections for reporting data about the battery to the host:
UsagePage(Power Device), Unit(none),
Usage(PresentStatus), Collection(Logical), ; Present status collection
Usage(Good),
UsagePage(Battery System), Usage(BelowRemainingCapacityLimit),
Usage(Charging), Usage(Discharging),
ReportSize(1), ReportCount(4), Logical Minimum (0), Logical Maximum (1), Unit(0),
Feature(Constant, Variable, Absolute, Volatile),
End Collection(), ; End of Present Status collection
UsagePage(Power Device),
Usage(ChangedStatus), Collection(Logical), ; Changed Status collection
Usage(Good),
UsagePage(Battery System), Usage(BelowRemainingCapacityLimit),
Usage(Charging), Usage(Discharging),
ReportSize(2), ReportCount(4), Logical Minimum (0), Logical Maximum (1),
Input(Data, Variable, Absolute, Volatile),
End Collection(), ; End of Changed Status collection
I only have a LiPo battery and a diode to charge it, so I am planning on taking out much of the rest of the power device stuff since I think I can get everything I want from the Battery System usage page. As a result I am looking at something more like (feel free to tell me if this is doomed form the start):
UsagePage(Battery System), Usage(BelowRemainingCapacityLimit),
Usage(Charging), Usage(Discharging),
ReportSize(1), ReportCount(3), Logical Minimum (0), Logical Maximum (1), Unit(0),
Feature(Constant, Variable, Absolute, Volatile),
Looking at the report from the spec, I have two questions:
Why is CapacityMode only size 1? The values are 0 - 3, isn't that a size 2?
What actually goes into the ChangedStatus collection? I see that the report sizes are 2 instead of 1 - are the reporting the old status on there as well? I'm not seeing anything elsewhere in the spec that gives an indication. In fact, the spec says that ChangedStatus elements should be boolean, which should be size 1, no?
CapacityMode can have values 0 to 3, but if your device only supports mode 0 (capacity measured in milliamp-hours) or mode 1 (capacity measured in milliwatt-hours) then I think it is ok to have a 1-bit wide field to record this. You could even define an 8-bit field that only stores the values 0 or 1 even though it could hold values up to 255.
I think the authors of the examples may have been trying to align the fields into 8 bits by making each of the 4 status bits 2-bits wide - so 0, would be stored as 00 and 1 would be stored as 01 in the report. Or it could have been a typo - I have seen many other examples in the USB specifications that have errors in them.
My problem is that I used the "read and write" example on the Arduino to re-write an RFID card (MIFARE Classic 1K) block by block. I started writing at block 4. At block 7 it stopped and now I can't read any sector. I wrote zeros to each block.
The DumpToSerial function just prints for every sector
PCD_Authenticate() failed: Timeout in communication.
It can still read the UID, the SAK, and the PICC type.
Did I destroy the card or can I recover it?
Some more info:
Card: MIFARE Classic 1K
Arduino Mega2560 from Elegoo
RC522 from the starter-kit
With MIFARE Classic 1K, every 4th block is the sector trailer (each 4 blocks are grouped into one sector). The sector trailer contains the access keys (key A on bytes 0..5, key B on bytes 10..15) and access conditions (access bits on bytes 6..8) for a sector.
The access conditions are protected by a redundancy mechanism where each access bit is present multiple times in positive and negative logic. A MIFARE Classic card allows overwriting these access conditions with invalid values (impossible combinations of access bits). However, once the access conditions are set to such an invalid value, the security logic of the chip will disable all access to the wole sector. Consequently, writing invalid access conditions to the sector trailer renders the whole sector unusable. This state is permanent and cannot be reverted.
You wrote all blocks starting at block 4 with all-zeros. Consequently, you wrote the sector trailer of sector 1 (in block 7) with the access conditions set to all-zeros. This is an invalid value for the access conditions. Therefore, sector 1 is permanently unusable. Since you indicated that you immediately received errors after writing block 7, you might be lucky and did not overwrite other sector trailers (e.g. block 11 for sector 2). In that case, those other sectors should still be usable. Similarly, since you started writing at block 4, the first sector (sector 0, blocks 0..3) should also still be accessible.
I'm using the Aconcagua measurement library in Pharo. I've had a lot of success using it to model things like days and kilometers, but have encountered an interesting problem where converting between units requires information on the underlying substance being measured. The formula for expressing the amount of a substance in air in parts per million, given the amount in milligrams per cubic meter is:
; where mw is the molecular weight of the material.
I'm envisioning usage like:
tlvCO := carbonMonoxide tlv. "returns the Threshold limit Value as 29 mg/m3"
...
tlvCO convertTo: PPM "where PPM is an Aconcagua unit"
The problem is that, while the examples I've seen of measurements in Aconcagua are contain in themselves all the info you need for conversion, in this case, you have to know the molecular weight of the underlying substance being measured. Thus mg/m3 -> ppm is not inherently meaningful. A properly formed question would be mg/m3 of ammonia -> ppm.
My instinct is to either:
create a new class like MaterialQuantity which has a material and a measure, or
create a special unit subclass that has a material
But I'm not 100% sold and would like some input...
I don't think that molecular weight is part of the unit, but part of a calculation, like the 24.45 (which is not clear, but it seems that is an average you consider for air molecular mass).
I am not sure that ppm is a unit that you can convert to a density unit, because they belong in different domains.
As far as i understand, you need to reify tlv as a compound unit or formula, which you can ask for the element. Then you could simply do something like [:tlv | tlv * ( 24.45 / tlv element) ]
Why does COBOL have both SECTION and PARAGRAPH?
Can anybody explain why the designers of COBOL created both SECTIONs and PARAGRAPHs? These have been around since the initial release of COBOL so I suspect the real reason for their existence has long since gone away (similar to things like NEXT SENTENCE which are still in the language specification for backward compatibility but no longer required since the introduction of explicit scope terminators).
My guess is that SECTION may have been introduced to support program overlays. SECTION has an optional PRIORITY number associated with it to identify the program overlay it is part of. However, most modern implementations of COBOL ignore or have dropped PRIORITY numbers (and overlays).
Currently, I see that SECTIONs are still required in the DECLARATIVE part of the PROCEDURE DIVISION, but can find no justification for this. I see no semantic difference between SECTION and PARAGRAPH other than PARAGRAPH is subordinate to SECTION.
Some COBOL shops ban the use of SECTION in favour of PARAGRAPH (seems common in North America). Others ban PARAGRAPH in favour of SECTION (seems common in Europe). Still others have guidelines as to when each is appropriate. All of this seems highly arbitrary to me - which begs the question: Why were they put into the language specification in the first place? And, do they have any relevance today?
If you answer this question, it would be great if you could also point to a reference to support your answer.
Thanks
No references on this, since I heard it passed on to me from one of the old timers in my shop but...
In the old COBOL compilers, at least for IBM and Unisys, sections were able to be loaded into memory one at a time. Back in the good old days when memory was scarce, a program that was too large to be loaded into memory all at once was able to be modularized for memory usage using sections. Having both sections and paragraphs allowed the programmer to decide which code parts were loaded into memory together if they couldn't all be loaded at once - you'd want two parts of the same perform loop loaded together for efficiency's sake. Nowadays it's more or less moot.
My shop uses paragraphs only, prohibits GOTO and requires exit paragraphs, so all our PERFORMS are PERFORM 100-PARAGRAPH THRU 100-EXIT or something similar - which seems to make the paragraphs more like sections to me. But I don't think that there's really much of a difference now.
I learned COBOL around 1978, on an ICL 2903. I have a vague memory that the SECTION headers could be assigned a number range, which meant that those SECTION headers could be swapped in and out of memory, when the program was too large for memory.
I know this is an old question, but the OP requested about documentation on the original justification of the use of SECTION as well as PARAGRAPH in COBOL.
You can't get much more "original" than the CODASYL Journal documentation.
in section 8 of the Journal's specification for the language,
"COBOL segmentation is a facility that provides a means by which the
user may communicate with the compiler to specify object program
overlay requirements"
( page 331, section 8.1 "Segmentation - General Description")
"Although it is not mandatory, the Procedure Division for a source
program is usually written as a consecutive group of sections, each of
which is composed of a series of closely related operations that are
designed to collectively perform a particular function. However s when
segmentation is used, the entire Procedure Division must be in
sections. In addition, each section must be classified as belonging
either to the fixed portion or to one of the independent segments of
the object program. Segmentation in no way affects the need for
qualification of procedure-names to insure uniqueness."
(p 331, section 8.1.2.1 "Program Segments")
In her book on comparative programming languages ("Programming Languages: History and Fundamentals", 1969) Jean Sammet (who sat on the CODASYL committee, representing Sylvania Electric) states:
".. The storage allocation is handled automatically by the compiler.
The prime unit for allocating executable code is a group of sections
called a segment. The programmer combines sections be specifying a
priority number with each section's name. ... The compiler is required
to see that the proper control transfers are provided so that control
among segments which are not stored simultaneously can take place.
..."
(p 369 - 371 V.3 COBOL)
Well, the simplest of the reasons is that SECTION s provide you the "modularity" -- just as functions in C -- a necessity in the "structured" programs. You would notice that code written using SECTIONs appears far more readable than the code written just in paragraphs, for every section has to have an "EXIT" -- a sole and very explicit exit point from a SECTION (exit point of a paragrpah is far more vague and implicit, i.e. until a new paragraph declaration is found). Consider this example and you may be tempted to use sections in your code:
*==================
MAINLINE SECTION.
*==================
PERFORM SEC-A
PERFORM SEC-B
PERFORM SEC-C
GOBACK.
*==================
MAINLINE-EXIT.
*==================
EXIT.
*==================
SEC-A SECTION.
*==================
.....
.....
.....
.....
IF <cond>
go to A-EXIT
end-if
.....
.....
.....
.....
.
*==================
A-EXIT.
*==================
EXIT.
Don't think you would have this sort of a privlege when writing your codes in paragraphs. You may have had to write a huge ELSE statement to cover up the statements you didn't want to execute when a certain condition is reached (consider that set of statements to be running across 2-3 pages... a further set of IF / ELSE would cramp you up for indentation). Of course, you'll have to use "GO TO" to achieve this, but you can always direct your professionals not to use GO TOs except while Exiting, which is a fair deal, I think.
So, whilst I also agree that anything that can be written using SECTIONs can also be written using paragraphs (with little or no tweaks), my personal choice would be to go for an implementation that can make the job of my developers a little easier in future!
Cobol was developed in the mid-50's. As the full name alludes, it was developed for business programming, as being a language more relevant for business purposes than the existing "scientific" or "technical" languages (there were very few "languages" anyway, and "machine code" (specific, of course, to a particular architechture (I nearly said "specific chip", before thinking of vacuum tubes)) which may have to be set through physical switches/dials on some machines) and if lucky with an "Assembler". Cobol was very advanced for its day, for its purpose.
The intention was for programs written in Cobol to be much more like English-language than just a set of "codes" which mean something to the initiated.
If you look at some of the nomenclature relating to the language - paragraph, sentence, verb, clause - it is deliberately following the patterns ascribed to the English language.
SECTION doesn't quite fit into this, until you relate things to a formal business document.
Both SECTIONs and paragraphs also appear outside the PROCEDURE DIVISION. As in written English, paragraphs can exist on their own, or can be a part of a SECTION.
SECTIONs may have a priority-number which relates to the "segmentation feature". This used to include "overlaying" of SECTIONs to afford a primitive level of memory management. This is a "computing featuer" rather than an English-language one :-) The "segmentation feature" does have something of a remaining affect, but I've never seen it actually used.
Without DECLARATIVES (which I don't use, and have just noticed the manual to be unclear upon) then it is "choice" as to whether SECTIONs or paragraphs are used for PERFORM.
If GO TO is used, rationally, "equivalence" can be achieved with PERFORM ... TRHU .... If not, and there is not gratuitous use of PERFORM ... THRU ..., then there is equivalence already.
Comparisons to "structured" code and modern languages are "reading history backwards" or just outlining a particular "practice". From the reputation attained by "spaghetti code" and ALTER ... TO PROCEED TO ... it may well be that for 20 years it was "common" to not do much with PERFORM unless you needed the "memory management", but I have no references or knowledge to back this up.
SECTIONs allow duplicate paragraph-names, otherwise paragraph-names must be unique.
I can't put a specific finger on one over the other all the time.
If using GO TO, I'd use SECTIONs. If not, paragraphs. With DECLARATIVES I'd use SECTIONs. If using SECTIONs I'd start PROCEDURE DIVISION with a SECTION to avoid a diagnostic message.
Local standards may dictate, but not necessarily on a "modern" (or even "rational") basis. Much is "known" but actually misunderstood about SECTIONs and paragraphs, in my experience.
For performance (where masses of data is being processed, and I mean masses) then a PERFORM of one SECTION rather than multiple individual paragraphs would see improvements. The effect would be the same with PERFORM ... THRU ..., but I prefer not to recommend it.
GO TO outside the range of a PERFORM is 1) bad 2) can lose out on "optimization". Shouldn't be a problem *except" when GO TO abend/exception and not expecting any logical return. If the use of this is felt to be necessarily "immediately", then it is better done with a PERFORM despite the "counter-intuitive" aspect (so document it).
For one thing, paragraph names must be unique unless they are in separate sections, so sections allow for "namespacing" of paragraphs.
If I recall correctly, the only reason you must use a SECTION is for DECLARATIVES. Aside from that they are optional and primarily useful for grouping paragraphs. I think it's common (relatively speaking, anyway) to require that PERFORM be used on paragraphs only when they are in the same section.
A section can have several paragraphs in it. When you PERFORM a section, it executes all the paragraphs in the section. Within the section you can use PERFORM or GOTO to branch to the paragraphs within the section.
I will do the best I can to answer this. If your only coding exposure is x86 or ARM then you will have significant difficulty. Yes those chips sell a lot but that doesn't mean they are good, just cheap enough people don't mind throwing them away.
Much of this information can be found in "The Minimum You Need to Know to Be an OpenVMS Application Developer." You will find it is one of the scant few titles on Dr. Dobb's recommended reading list for all developers. Yes, I wrote it. It is also the book recommended by HP OpenVMS Engineering group for developers looking to learn the platform.
My COBOL on that platform mostly happened during the 1980s when it was VAX/VMS. Then it became OpenVMS; Alpha/OpenVMS; Itanium/OpenVMS; and soon to be x86/OpenVMS. On a real computer with a real operating system, sections have meaning. Every section created a PSECT. In linker terms that was short for Program SECtion. Based on what the section was, various load attributes were set. Each PSECT would be loaded into one or more 512 Byte memory pages. Memory pages were designed to be the exact same size as a disk block. VMS stood for Virtual Memory System. IBM had several of their own operating systems which, under the hood were different, but they too were true virtual memory systems. This wasn't "overlay linking." That's an x86 term and came about due to severe architectural flaws.Read up on Compact, Small, Medium, and Large "memory models" from the 286 days on forward. Also read up on EMS and XMS memory paging. Oiy was THAT fun!
Here is one of the numerous programs found in that book.
IDENTIFICATION DIVISION.
PROGRAM-ID. COB_ZILL_DUE_REPORT_SUB.
AUTHOR. Roland Hughes.
DATE-WRITTEN. 2005-02-08.
DATE-COMPILED. TODAY.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT DRAW-STATS
ASSIGN TO 'DRAWING_STATS'
ORGANIZATION IS INDEXED
ACCESS MODE IS SEQUENTIAL
RECORD KEY IS ELM_NO IN DSTATS-REC
LOCK MODE IS AUTOMATIC
FILE STATUS IS D-STAT.
SELECT MEGA-STATS
ASSIGN TO 'MEGA_STATS'
ORGANIZATION IS INDEXED
ACCESS MODE IS SEQUENTIAL
RECORD KEY IS ELM_NO IN MSTATS-REC
LOCK MODE IS AUTOMATIC
FILE STATUS IS M-STAT.
SELECT SORT-FILE ASSIGN TO 'TMP.SRT'.
SELECT SORTED-FILE ASSIGN TO DISK.
SELECT RPT-FILE ASSIGN TO 'ZILL_DUE.RPT'.
DATA DIVISION.
FILE SECTION.
FD DRAW-STATS
IS GLOBAL
LABEL RECORDS ARE STANDARD.
COPY 'CDD_RECORDS.ZILLIONARE_STATS_RECORD' FROM DICTIONARY
REPLACING ZILLIONARE_STATS_RECORD BY DSTATS-REC.
FD MEGA-STATS
IS GLOBAL
LABEL RECORDS ARE STANDARD.
COPY 'CDD_RECORDS.ZILLIONARE_STATS_RECORD' FROM DICTIONARY
REPLACING ZILLIONARE_STATS_RECORD BY MSTATS-REC.
FD RPT-FILE
LABEL RECORDS ARE OMITTED.
01 RPT-DTL PIC X(80).
SD SORT-FILE.
COPY 'CDD_RECORDS.ZILLIONARE_STATS_RECORD' FROM DICTIONARY
REPLACING ZILLIONARE_STATS_RECORD BY SORT-REC.
FD SORTED-FILE
VALUE OF ID IS SORTED-FILE-NAME.
COPY 'CDD_RECORDS.ZILLIONARE_STATS_RECORD' FROM DICTIONARY
REPLACING ZILLIONARE_STATS_RECORD BY SORTED-REC.
Data declarations
WORKING-STORAGE SECTION.
01 CONSTANTS.
05 SORT-FILE-NAME PIC X(7) VALUE 'TMP.SRT'.
05 SORTED-FILE-NAME PIC X(8) VALUE 'STAT.SRT'.
01 STATUS-VARIABLES.
05 M-STAT PIC X(2).
05 D-STAT PIC X(2).
05 EOF-FLAG PIC X.
88 IT-IS-END-OF-FILE VALUE 'Y'.
01 STUFF.
05 TODAYS-DATE.
10 TODAY_YYYY PIC X(4).
10 TODAY_MM PIC X(2).
10 TODAY_DD PIC X(2).
05 TODAYS-DATE-FORMATTED.
10 FMT_MM PIC Z9.
10 FILLER PIC X VALUE '/'.
10 FMT_DD PIC 99.
10 FILLER PIC X VALUE '/'.
10 FMT_YYYY PIC 9(4).
05 FLT-1 COMP-2.
05 WORK-STR PIC X(65).
01 REPORT-DETAIL.
05 ELM-NO-DTL PIC Z9.
05 FILLER PIC X(3).
05 HIT-COUNT-DTL PIC ZZZ9.
05 FILLER PIC X(3).
05 SINCE-LAST-DTL PIC ZZZ9.
05 FILLER PIC X(5).
05 PCT-HITS-DTL PIC Z9.999.
05 FILLER PIC X(4).
05 AVE-BTWN-DTL PIC ZZ9.999.
01 REPORT-HDR1.
05 THE-DATE PIC X(12).
05 FILLER PIC X(20).
05 PAGE-TITLE PIC X(17).
01 REPORT-HDR2.
05 FILLER PIC X(33).
05 GROUP-TITLE PIC X(20).
01 REPORT-HDR3.
05 HDR3-TXT PIC X(40) VALUE
'No Hits Since Pct_hits Ave_btwn'.
01 REPORT-HDR4.
05 HDR4-TXT PIC X(40) VALUE
'-- ---- ----- -------- --------'.
PROCEDURE DIVISION.
A000-MAIN.
PERFORM B000-HSK.
SORT SORT-FILE
ON DESCENDING KEY SINCE_LAST IN SORT-REC
INPUT PROCEDURE IS S000-DSTAT-INPUT
GIVING SORTED-FILE.
PERFORM B010-REPORT-DRAWING-NUMBERS.
STRING SORT-FILE-NAME, ';*' DELIMITED BY SIZE INTO WORK-STR.
CALL 'LIB$DELETE_FILE' USING BY DESCRIPTOR WORK-STR.
STRING SORTED-FILE-NAME, ';*' DELIMITED BY SIZE INTO WORK-STR.
CALL 'LIB$DELETE_FILE' USING BY DESCRIPTOR WORK-STR.
*
* Set up for second part of report
*
MOVE SPACES TO RPT-DTL.
WRITE RPT-DTL BEFORE ADVANCING PAGE.
MOVE SPACES TO EOF-FLAG.
MOVE ' Mega Drawing Numbers' TO GROUP-TITLE.
SORT SORT-FILE
ON DESCENDING KEY SINCE_LAST IN SORT-REC
INPUT PROCEDURE IS S001-MSTAT-INPUT
GIVING SORTED-FILE.
PERFORM B010-REPORT-DRAWING-NUMBERS.
STRING SORT-FILE-NAME, ';*' DELIMITED BY SIZE INTO WORK-STR.
CALL 'LIB$DELETE_FILE' USING BY DESCRIPTOR WORK-STR.
STRING SORTED-FILE-NAME, ';*' DELIMITED BY SIZE INTO WORK-STR.
CALL 'LIB$DELETE_FILE' USING BY DESCRIPTOR WORK-STR.
CLOSE RPT-FILE.
CALL 'LIB$SPAWN' USING BY DESCRIPTOR 'EDIT/READ ZILL_DUE.RPT'.
EXIT PROGRAM.
Paragraph to initialize our data and files.
B000-HSK.
CALL 'COB_FILL_IN_LOGICALS'.
MOVE SPACES TO STATUS-VARIABLES.
ACCEPT TODAYS-DATE FROM DATE YYYYMMDD.
MOVE TODAY_YYYY TO FMT_YYYY.
MOVE TODAY_DD TO FMT_DD.
MOVE TODAY_MM TO FMT_MM.
OPEN OUTPUT RPT-FILE.
MOVE SPACES TO REPORT-HDR1.
MOVE TODAYS-DATE-FORMATTED TO THE-DATE.
MOVE 'Due Number Report' to PAGE-TITLE.
MOVE SPACES TO REPORT-HDR2.
MOVE 'Drawing Numbers' TO GROUP-TITLE.
Paragraph to process the sorted selection file and
create the portion of the report relating to drawing
numbers.
B010-REPORT-DRAWING-NUMBERS.
MOVE SPACES TO EOF-FLAG.
OPEN INPUT SORTED-FILE.
READ SORTED-FILE
AT END SET IT-IS-END-OF-FILE TO TRUE.
PERFORM C010-DRAWING-HEADINGS.
PERFORM UNTIL IT-IS-END-OF-FILE
MOVE SPACES TO REPORT-DETAIL
MOVE ELM_NO IN SORTED-REC TO ELM-NO-DTL
MOVE HIT_COUNT IN SORTED-REC TO HIT-COUNT-DTL
MOVE SINCE_LAST IN SORTED-REC TO SINCE-LAST-DTL
MOVE PCT_HITS IN SORTED-REC TO PCT-HITS-DTL
MOVE AVE_BTWN IN SORTED-REC TO AVE-BTWN-DTL
MOVE REPORT-DETAIL TO RPT-DTL
WRITE RPT-DTL BEFORE ADVANCING 1 LINE
READ SORTED-FILE
AT END SET IT-IS-END-OF-FILE TO TRUE
END-READ
END-PERFORM.
CLOSE SORTED-FILE.
Paragraph to print headings for the main drawing numbers
Which are due.
C010-DRAWING-HEADINGS.
MOVE SPACES TO RPT-DTL.
MOVE REPORT-HDR1 TO RPT-DTL.
WRITE RPT-DTL BEFORE ADVANCING 2 LINES.
MOVE SPACES TO RPT-DTL.
MOVE REPORT-HDR2 TO RPT-DTL.
WRITE RPT-DTL BEFORE ADVANCING 1 LINE.
MOVE SPACES TO RPT-DTL.
MOVE REPORT-HDR3 TO RPT-DTL.
WRITE RPT-DTL BEFORE ADVANCING 1 LINE.
MOVE SPACES TO RPT-DTL.
MOVE REPORT-HDR4 TO RPT-DTL.
WRITE RPT-DTL BEFORE ADVANCING 1 LINE.
Paragraph to filter due numbers into sort file.
Creates a floating point temporary to compare against
floating point value from input file. When greater
record is released to the sort file.
S000-DSTAT-INPUT.
OPEN INPUT DRAW-STATS.
READ DRAW-STATS NEXT
AT END SET IT-IS-END-OF-FILE TO TRUE.
PERFORM UNTIL IT-IS-END-OF-FILE
MOVE SINCE_LAST IN DSTATS-REC TO FLT-1
IF FLT-1 >= AVE_BTWN IN DSTATS-REC
MOVE DSTATS-REC TO SORT-REC
RELEASE SORT-REC
END-IF
READ DRAW-STATS
AT END SET IT-IS-END-OF-FILE TO TRUE
END-READ
END-PERFORM.
CLOSE DRAW-STATS.
Paragraph to filter due numbers into sort file.
Creates a floating point temporary to compare against
floating point value from input file. When greater
record is released to the sort file.
S001-MSTAT-INPUT.
OPEN INPUT MEGA-STATS.
READ MEGA-STATS NEXT
AT END SET IT-IS-END-OF-FILE TO TRUE.
PERFORM UNTIL IT-IS-END-OF-FILE
MOVE SINCE_LAST IN MSTATS-REC TO FLT-1
IF FLT-1 >= AVE_BTWN IN MSTATS-REC
MOVE MSTATS-REC TO SORT-REC
RELEASE SORT-REC
END-IF
READ MEGA-STATS
AT END SET IT-IS-END-OF-FILE TO TRUE
END-READ
END-PERFORM.
CLOSE MEGA-STATS.
END PROGRAM COB_ZILL_DUE_REPORT_SUB.
Sorry for the way the "code" feature works in this editor.
Certain sections have to exist. Your program cannot do I-O without an INPUT-OUTPUT SECTION. This is where you map names to physical storage.
If you have an INPUT-OUTPUT SECTION then you have to have a FILE SECTION. This is where you define the record layout(s) of each named file. LABEL RECORDS are always STANDARD when dealing with disk data files and OMITTED when writing report text files. There are a few other clauses I don't remember. Please note the SD included in all of those FD statements. FD is File Definition and SD is Sort Definition.
If you are going to have any local variables you have to have a WORKING-STORAGE SECTION. You cannot declare variables on the fly, they all have to be declared here. This PSECT gets a DATA segment attribute among other things. If you call some service or something and it has a bad address, attempting to execute code within this PSECT the operating system will shoot your application out of the saddle.
All PSECTs created after PROCEDURE DIVISION are flagged EXEC, write protected. If you try to overwrite anything in here during execution the operating system will shoot your program out of the saddle. Any other program attempting to write here will also be shot out of the saddle.
Scan down to the SORT SORT-FILE in A000-MAIN. The COBOL sort routine is amazing. Notice that I provided an INPUT PROCEDURE and it is a paragraph. On IBM mainframes running ROSCOE back in the day this had to be an INPUT SECTION. They needed different attributes on the PSECT so the system sort routine could read/write.
Here is a snippet from another program in that book.
*
* FMS definitions
*
COPY 'COBFDVDEF' OF 'MEGA_TEXT_LIB'.
LINKAGE SECTION.
01 FMS-STUFF.
05 FMSSTATUS PIC S9(9) COMP.
05 RMSSTATUS PIC S9(9) COMP.
05 TCA PIC X(12).
05 WORKSPACE PIC X(12).
PROCEDURE DIVISION USING FMS-STUFF.
The linkage section creates a PSECT of sharable memory. When you call external routines which return values, they need to be here.You must also grant your PROCEDURE DIVISION access to various things it needs in the linkage section.
As you can see from this snippet later in the code
B010-USER-INPUT.
PERFORM C000-FORWARD-LOAD
CALL 'FDV$PUTAL' USING BY DESCRIPTOR SCREEN-REC.
MOVE SPACES TO WORK-STR.
CALL 'FDV$GETAL' USING BY DESCRIPTOR WORK-STR
BY REFERENCE TERMINATOR.
EVALUATE TERMINATOR
WHEN FDV$K_FK_E6 SET LOAD-FORWARD TO TRUE
WHEN FDV$K_FK_E5 SET LOAD-REVERSE TO TRUE
WHEN FDV$K_FK_F10 SET WE-ARE-DONE TO TRUE
END-EVALUATE.
you can pass any local variable you wish as long as you pass it correctly. It's the writing which needs special PSECT attributes.
It's late and I'm tired but I seem to remember you could could have USING clauses on SECTION declarations in the PROCEDURE DIVISION. The on-line documentation available for COBOL, at least that indexed by GOOGLE really is quite worthless. If you want more detailed information search for a circa 1980s COBOL textbook. It won't have any of the new stuff but it will answer many questions.
Here's a kind of bad tutorial on COBOL structure.
We use COBOL SECTION coding in all of our 37K MVS batch COBOL programs. We use this technique to get much faster run times and significantly reduced CPU overhead. This COBOL coding technique is very similar to high performance batch assembler.
Call it High Performance Functionally Structured COBOL programming
Once a SECTION is defined all PERFORM xxxxx will return at the next coded SECTION not the next paragraph in the SECTION. If paragraphs are coded ahead of the first SECTION then they can be executed normally. (But we don't allow this)
Using a SECTION has higher overhead than when using and PERFORM ing only paragraphs - U N L E S S - you use GOTO logic to bypass code that should be conditionally executed. Our rule is that a GOTO can only point to a Tag-Line in the same SECTION. (a paragraph) All paragraphs in a SECTION must be a sub function of the SECTION s function. The EXIT instruction is an assembler NOP instruction. It allow for a Tag-Line to be placed before the next SECTION - a fast exit/return.
Executing a PERFORM xxxx THRU yyyy has more CPU overhead than execution a SECTION without the GOTO s.
WARNING: Executing a PERFORM xxxx Tag-Line in a SECTION will fall thru all the code in the SECTION until the next SECTION is encountered. A GOTO Tag-Line outside of the current SECTION will fall thru all the code in the new landing SECTION until the next SECTION is encountered. (But we don't allow this)