To: J3 J3/99-115 From: JOR Page 1 of 4 Subject: Edits for J3 notes, chapters 9-10 Date: March 3, 1999 Here are the edits to resolve most of the J3 internal notes in 99-007 from chapters 9 and 10. If Van's paper on unit numbers for "*" passes, unresolved issues 63 and 64 could be addressed. If Malcolm's paper on formatted stream I/O passes, unresolved issue 68 could be addressed. Unresolved issue 28: section 9.3 (internal files), [171:10+], add these new list items: (10) The initial rounding mode is processor dependent for an internal file. (11) The initial decimal edit mode is POINT for an internal file. Typo correction section 9.4.4.11, [176:39], change "more" to "mode" Unresolved issue 29: section 9.4.4.6, [175:34-37], replace "If NULL is specifed ..... treated as zeros." with It specifies the inital form of the blank interpretation mode (10.6.6) for all formatted input/output for this connection. section 10.6.6, [223:12], change "to specify" to "to specify the blank interpretation mode. The form of this mode controls" Unresolved issue 1: section 9.5.1.11, [183:31] change "When" to "If" Unresolved issue 4: section 9.5.1.11, [184:5+], add the following Within a scoping unit, a pending I/O storage sequence <> is a variable that is referenced or defined, and whose definition or reference refers to any storage unit in any pending I/O storage sequence. Note that a variable may be a pending I/O storage sequence affector in one scoping unit, but not in some other scoping unit, since pending I/O storage sequences only exist for the duration of an asynchronous data transfer operation (9.6). J3/99-115 Page 2 of 4 Unresolved issue 8: delete J3 internal note [185:39-46]. Unresolved issue 69: in note 9.32 [186:7], change "scalar and of intrinsic type" to "scalar" also [186:9-10], delete " of intrinsic type" section 9.5.2, [186:4+], add All scalar objects resulting when a data transfer statement's list items are expanded according to the rules in this section for handling array and derived type list items are called <>. Zero sized arrays and implied-DO lists with an iteration count of zero are ignored and are not considered to be effective list items. A scalar character item of zero length is an effective list item. section 9.5.4.4, [190:6-8] Delete The next item to be processed in the list is called the next effective item. Zero-sized arrays and implied-DO lists with iteration counts of zero are ignored in determining the next effective item. A scalar character item of zero character length is treated as an effective item. [190:12], add the following after "namelist-group-object-list." The next item to be processed is called the next effective item. Effective items are derived from the input/output list items as described in 9.5.2. Unresolved issue 3: Section 9.5.4, [188:2-3] replace execution of the current data transfer statement is terminated with steps 4-8 are skipped for the current data transfer statement and the IOSTAT and ERRMSG variables are set to values determined by the WAIT operation. note to Richard Maine, the text assumes that an error cannot occur when positioning the file after the data transfer, because, in an implementation, that positioning is part of the data transfer operation, and would have triggered an error in step (6). Your note about getting an error when identifying the unit is correct, but a non-existent unit won't have any pending i/o operations, and establishing the format is ok. I'd rather not skip the parts about transfering data, because it might suggest that one can have undefined/not associated list items if the unit number is bad. Not a good suggestion. So i'd suggest leaving this list a little vague about what happens for errors when identifying the unit. J3/99-115 Page 3 of 4 Unresolved issue 23: Section 9.5.4.4.3 [195:12-14] replace the whole paragraph with If the parent data transfer statement is a READ statement, the processor shall define the effective list item from the parent READ statement with the value assigned to the dumy argument (or some portion thereof) by the user defined derived type input procedure. [195:15-16] replace "the dummy argument shall have the value of the list item" with "the processor shall provide the value of the effective list item in the dummy argument" [195:17-20] replace The argument shall have the user-specified values from the the v-list of the edit descriptor. The argument shall have with The processor shall provide the values from the v-list of the edit descriptor in the dummy argument, with Unresolved issue 70: section 9.2.3.2, [169:29+] Add the following paragraph, File positioning for child data transfer statements is described in 9.5.4.4.3. section 9.5.4.4.3 [196:1-19], replace [196:1-19] with Since a child data transfer statement does not position the file prior to data transfer, the child data transfer statement starts transfering data from wherever the file was positioned by the parent data transfer statement after processing the last effective list item or last record positioning edit descriptor. This is usually in the middle of a record. Unresolved issue 25: Section 9.8.1.28, [206:20+], add the following: The processor shall return PROCESSOR_DEFINED only if the current rounding control in effect behaves differently than the UP, DOWN, ZERO and NEAREST modes. also delete [206:25:31] Unresolved issue 30: The addition for issue 25 make this issue moot, and the note refered to should be deleted. Section 9.8.1.28 [21:24], delete Note 9.57 J3/99-115 Page 4 of 4 Unresolved issue 24: This is still unresolved. We will probably add many more tables for G formatting, 1 or 2 per rounding mode, to get everything just right (3 or 4 revisions from now) Unresolved issue 31: We will introduce a new term, <>, instead of decimal point, which is defined as "." or "," depending on the current decimal edit mode. Add a new section, 10.5 (and renumber the existing 10.5 and later sections): 10.5 Decimal symbol The <> is the character that appears after the units digit in the decimal representation of a real value in an internal or external file. When the decimal edit mode is POINT, the decimal symbol is a decimal point. When the decimal edit mode is COMMA, the decimal symbol is a comma. Globally change "decimal point" to "decimal symbol" EXCEPT for these (do this global change before entering text just above for issue 31): Do not change chapter 3, or [224:5] [225:41] replace decimal point, or a comma if the decimal edit mode is COMMA, with decimal symbol Unresolved issue 65: asks if we should allow a ";" as a value separator even when the decimal mode is ".". If we do, then we break (subtlely) compatibility with F95, where an undelimited character constant in namelist input can contain a ";" as long as the decimal edit mode is PERIOD. My inclination is to say no. We force the user to get "." or "," correct for the decimal symbol, so why not require the correct separator. Delete [224:28-31] (unresolved issue 65)