HP 3000 Manuals HP 3000 Manuals
Operation
This section describes how Enhanced ACCEPT and DISPLAY statements are
handled at run time when used with:
* Elementary data items.
* Group items.
* Screen Section items.
The term field used in relation to screen handling refers to an area on
the screen that corresponds to a single data item during ACCEPT and
DISPLAY operations.
Single Field ACCEPT and DISPLAY Statements
This section describes how ACCEPTand DISPLAY statements in the following
format are handled at run time:
display data-item at xxyy...
accept data-item at xxyy ...
where:
data-item is an elementary item defined in the Data Division of your
program.
xxyy specifies the position on the screen (xx=line, yy=column)
where the DISPLAY or ACCEPT field starts. The length of
the field is governed by the length and type of data-item,
and the SIZE clause.
Adis does not display a character at the last position on the screen (for
example, line 25 column 80 on a 25 line screen). This is because some
terminals scroll automatically when a character appears in this position,
giving different results on different hardware. If a character is
displayed at a position off the screen, Adis scrolls the display such
that it is visible. (UNIX)
You are also recommended to avoid displaying at the last position of the
screen on some non-UNIX environments, since scrolling can also occur.
Single Field ACCEPT Statements.
The following sections describe how the ACCEPT statement is executed on
different types of fields.
Alphanumeric Fields.
The term alphanumeric field is used here to cover all alphanumeric,
alphabetic and alphanumeric-edited fields. For the purposes of an ACCEPT
statement, an alphanumeric-edited field is treated as an alphanumeric
field of the same length. Any insertion symbols such as the forward
slash character (/) or zero are ignored and treated as an X. Therefore, a
field defined as PIC XX0XX0XX is treated as if it was specified as PIC
X(8).
If the field is defined as alphabetic, only the characters "A" to "Z",
"a" to "z" and space are allowed into the field.
The cursor is initially placed at the start of the field. As data is
entered into the field, the cursor advances to the next character. The
cursor can be moved back over the data in the field using the cursor
keys, and editing functions such as backspace and delete are provided.
Numeric and Numeric-edited Fields.
The form of data entry for numericand numeric-edited fields can be one of
the following:
* Fixed format.
* Free-format.
* RM style.
Use Adiscf to select the style you want. The default form of data entry
is fixed format. You should experiment with free-format to see which
method you prefer, especially when accepting into simple numeric fields.
The three styles are described below, followed by notes on data entry in
general. If you have compiled your program with the MS"2" Compiler
directive, you should also read the section Microsoft COBOL V2.2
Emulation later in this chapter.
Fixed Format Data Entry.
This is also known as formatted
format data entry|mode. It can best be described as "What you see is
what you get". As each key is pressed, the field is automatically
reformatted to conform to the picture string. Therefore, Adis tries to
ensure that the field always looks on the screen as it is stored in the
Data Division, and its size is the same as the size of the data item.
Therefore, as with the DISPLAY statement, it is only really sensible to
accept fields that are defined as USAGE DISPLAYwith no implied sign or
decimal point.
During data entry, characters other than numeric digits, the plus sign
(+), minus sign (-) and the decimal point (.) are rejected. Insertion
characters in edited fields are automatically skipped over as the cursor
is moved backward and forward. Any sign indicator is automatically
modified if a + or - is pressed, regardless of where the cursor is in the
field.
Zeros are allowed as insertion charactersonly as a leading symbol before
a decimal point, or as a trailing symbol following a decimal point. For
example, PIC 0.9999 and PIC 999.90 are valid, but PIC 0.0009 and PIC
999.000 are not.
Data entry of simple numeric and numeric-edited fields with no zero
suppressionis similar to that for alphanumeric fields, except that insert
mode is not supported in numeric and numeric-edited fields. If the
decimal point character is pressed in a simple numeric field, the digits
are right justified. For example, a field defined as PIC 9(5) which
initially contains zeros is accepted as follows (bold characters indicate
cursor position):
Initial display 00000
Pressing 1 gives 10000
Pressing 2 gives 12000
Pressing 4 gives 12400
Pressing Backspace gives 12000
Pressing "." gives 00012
Data entry into zero-suppressed fields is handled differently. The
cursor is initially placed on the first character position that is not
zero-suppressed. If all the digits before the decimal point are
suppressed, the cursor is positioned on the decimal point itself.
While the cursor is to the left of
the decimal point; that is, in the integer part of the field, the cursor
moves to the right as digits are entered until the decimal point is
reached. Any further digits are inserted immediately before the decimal
point until all the integer places are filled. The cursor is then
automatically moved to the first decimal digit and advances as the
decimal digits are entered.
If you wish to enter digits after the decimal point when there are
integer places still unfilled, the decimal point (.) must be entered.
For example, assume that a numeric-edited data field is defined as PIC
ZZZ99.99 and initially contains zeros, the field is displayed as follows
during the ACCEPT:
Initial display 00.00
Pressing 1 gives 10.00
Pressing 2 gives 12.00
Pressing 3 gives 123.00
Pressing 4 gives 1234.00
Pressing Backspace gives 23.00
Pressing 5 gives 1235.00
Pressing 6 gives 12356.00
Pressing 7 gives 12356.70
Pressing 8 gives 12356.78
If you want to enter 123.45 into the same field, the field appears as
follows:
Initial display 0.00
Pressing 1 gives 10.00
Pressing 2 gives 12.00
Pressing 3 gives 123.00
Pressing "." gives 123.00
Pressing 4 gives 123.40
Pressing 5 gives 123.45
Fixed format mode is only allowed on numeric-edited data items of length
up to 32 characters. If they are longer than 32 characters, they are
automatically handled in free-format modeas described below. Fields are
also automatically treated as free-format if a SIZE clauseis specified in
the ACCEPT statement.
Free-format Data Entry.
Free-formatmode can be selected for either numeric fields or
numeric-edited fields or both. This can be done using Adiscf (See the
section Altering Accept/Display Options in the chapter Adis Configuration
Utility (Adiscf)) for more information.
During data entry into a free-format field, the field is treated as an
alphanumeric field of the appropriate length. It is only when the user
leaves the field that it is reformatted to comply with the picture
string. Any characters other than the digits, the sign character and the
decimal point character are discarded.
Fields occupy the same number of characters on the screen as they do
bytes in memory, with the exception that an additional character is
allocated for implied signs and decimal points. Therefore, a data item
defined as PIC S99V99 occupies six characters on the screen in
free-format mode as opposed to four characters in fixed-format mode.
It is advisable to compile the program with the DE-EDIT"1" Compiler
directive set, since free format allows data that does not conform to the
screen item's PICTURE clause; with DE-EDIT"2" this is interpreted as
zeros when moved to the USING or TO data item. See the appendix
Directives for Compiler for details of the DE-EDIT directive.
Data entry is the same as for alphanumeric fields.
If an enhanced ACCEPT statement is being used, the clauses SPACE-FILL,
ZERO-FILL, LEFT-JUSTIFY, RIGHT-JUSTIFY and TRAILING-SIGN are applicable
only to free-format non-edited fields (and are ignored with fixed-format
fields). See the description of the ACCEPT statement in your Language
Reference for further details of these clauses.
RM Style Data Entry.
RM styledata entry is selected using the appropriate Accept/Display
option in Adiscf. It is provided for emulation of numeric and
numeric-edited ACCEPT operations in RM/COBOL V2.0. If this mode is
selected, all other Accept/Display option numeric and numeric-edited data
entries are ignored. Data entry is the same as for alphanumeric fields.
All ACCEPT and DISPLAY statements behave as if the phrase MODE IS BLOCK
has been specified. See the section The MODE IS BLOCK Clause for more
information. This style of numeric input is not intended for use with
the screen handling syntax in this COBOL system, only with programs
originally written for RM/COBOL.
General Data Entry.
These notes concern the accepting of data into fields:
* If a field is too long to fit on one line of the screen, it is
split into separate subfields at run time. Each subfield fits
entirely onto one line. The cursor auto-skips to the next
subfield at the end of one subfield, regardless of the setting of
any auto-skipcontrols.
For example, if you accept a data item that is PIC X(190) at line
1, column 1 and the screen is only 80 characters wide, the field
is broken into three subfields, two with 80 characters and one
with 30 characters.
* If a field extends beyond the end of the screen, the action taken
depends on the type of field:
* Alphanumeric fields are truncated to a size that fits on
the screen.
* Numeric and numeric-edited fields are treated as if they
were defined as FILLER; that is, not a field, and are
ignored.
* As most terminals scroll upward as a result of a character
appearing in the final character position of the screen (bottom
right) it is not possible to use this character position as part
of an ACCEPT statement.
Microsoft COBOL V2.2 Emulation.
The style of data entry into numeric and numeric-edited fields in
Microsoft's COBOL Version 2.2is quite different from the style used in
this product. The main difference is that decimal points and implied
signs are treated as if they were specified as "." and "-". Therefore, a
PIC S99V99 field is treated as if it was specified as a -99.99 field
during execution of an ACCEPT or DISPLAY statement under Microsoft COBOL
V2.2. All ACCEPT and DISPLAY statements behave as if the phrase MODE IS
BLOCK has been specified.
To support this action in this product, if the MS"2" Compiler directiveis
specified when your program is compiled, the Compiler generates
additional temporary data items for the ACCEPT and DISPLAY. For a field
defined as PIC S99V99, the Compiler creates an additional numeric-edited
field of picture -99.99 and generates the necessary moves into and out of
the edited field before and after a DISPLAY or ACCEPT. This action is
transparent to you, but you should be aware of the differences in ACCEPT
and DISPLAY behavior if MS"2" is specified.
The other major difference between the behavior of this COBOL system and
Microsoft COBOL V2.2 during execution of a numeric ACCEPT is that
Microsoft COBOL V2.2 accepts data from right to left, whereas this COBOL
accepts data from left to right. This feature of Microsoft COBOL V2.2 is
not supported in this product.
Single Field |DISPLAY Statements.
The following sections describe the way that the DISPLAY statement
functions.
Format of Displayed Data.
When a data item is displayed on the screen, it normally occupies the
same number of characters on the screen as it does bytes in memory. The
only exceptions are DBCS encoding schemes such as EUC which includes
characters which differ in storage space and display size. The following
examples assume such characters do not occur.
Data Size on Screen Comment
Description
---------------------------------------------------
X(5) 5 characters
N(5) 10 characters Each PIC N
character occupies
2 bytes in memory.
G(5) 10 characters Each PIC G
character occupies
2 bytes in memory.
9(5) 5 characters
99.99 5 characters
Z(4)9 5 characters
99V99 4 characters V is an implied
decimal point and
so is not displayed
on the screen.
S9(4) 4 characters The sign is implied
and so is not
displayed on the
screen.
S9(4) SIGN 5 characters
LEADING
SEPARATE
9(4) COMP 2 characters COMP fields are
stored in binary; a
9(4) COMP field
occupies 2 bytes in
memory.
As you can see from the above examples, it is only really sensible to
display fields defined as USAGE DISPLAYwhich do not contain implied signs
or decimal points. When the field is displayed, it is copied
byte-for-byte from the data item onto the screen at the required
position.
NOTE ANSI DISPLAY operations convert non-USAGE DISPLAY numeric items to
USAGE DISPLAY before displaying.
Control Sequences in Displayed Data.
Control sequences cannot be embedded in the data that is displayed. If
you do embed control codes (that is, ASCII codes less than 32) into the
data, the character corresponding to that code is displayed. For
example, displaying ASCII code 7 results in a diamond character being
displayed instead of sounding the bell. (In some environments, such
characters are replaced by a space.) All highlighting and cursor control
must be done through the syntax provided.
Control Sequences using the COBCTRLCHAR variable.
On UNIX, the COBCTRLCHARenvironment variable is provided for
backward compatibility. When set to Y or y, control codes are
passed transparently to the terminal. This has the following
consequences:(UNIX)
* The display is terminal-dependent.
* A corrupted display is likely if, for example, a code is sent
which moves the cursor, so the screen handling routines have an
incorrect record of the screen status.
* Extra facilities, such as generic line drawing, wide terminal
support and direct printing to an attached printer, are not
available.
* Programs with escape sequences cannot be animated.
* Automatic new line handling is not supported and all output goes
directly to the terminal, thus making it your responsibility
either to use explicit cursoraddressing, or to ensure that the
correct control codes are output for that particular terminal in
your particular configuration.
To avoid these consequences, leave COBCTRLCHAR unset, or set it to N or
n.
Displaying Highlighted Text.
If you use the CRT-UNDER phrase in a DISPLAY statement, the data item is
displayed with an attribute to make the display stand out from normal
displayed text. Depending on your environment, use of the CRT-UNDER
phrase might cause data items to be displayed underlined, highlighted,
colorized or in reverse video. This can be changed using Adiscf. See
the chapter Adis Configuration Utility (Adiscf) for more information.
Accepting and Displaying Group Items
When displaying or accepting group items, each elementary item within the
group is treated as a separate field. If an elementary item is defined
as FILLER, it is simply used as a positioning item of the appropriate
size; that is, you cannot accept into FILLER items or display FILLER
items.
Accepting into Group Items.
When accepting into a group item, each field is accepted into as
described for single-field ACCEPT statements (see the section Single
Field ACCEPT Statements).
Unless you explicitly position the cursor (see the section The CURSOR IS
Clause), the cursor is initially placed at the start of the first field.
When the end of a field is reached, the cursor is normally advanced to
the beginning of the next field automatically. This action can be
prevented by turning off auto-skip (Accept/Display option 7 in Adiscf,
see the chapter Adis Configuration Utility (Adiscf)). The cursor keys,
and the keys set up for next and previous field operations (usually Tab
and Backtab) move the cursor around the fields.
Displaying Group Items.
Consider the following group item:
01 display-item.
03 display-item-1 pic x(20).
03 filler pic x(35).
03 display-item-2 pic 9(10).
03 filler pic x(105).
03 display-item-3 pic z(4)9.
If the following statement is executed on a screen 80 characters wide:
display display-item at 0101
display-item-1 is displayed at row 1, column 1, display-item-2 is
displayed at row 1, column 56, and display-item-3 is displayed at row 3,
column 11
All other areas of the screen are unaffected by this DISPLAY statement.
FILLER items do not cause any data to be displayed on the screen.
Consequently, data already on the screen in the positions defined by each
FILLER is not altered in any way by this DISPLAY statement.
If a data item is defined as follows :
01 data-item.
03 data-char pic x occurs 2000.
and the following statement is executed:
display data-item at 0101
then this is treated as a display of 2000 fields, each defined as PIC X,
which is unlikely to be what you require. To avoid this, either redefine
data-item as a PIC X(2000) and display that, or use the MODE IS BLOCK
clause described in the section The MODE IS BLOCK Clause.
The MODE IS BLOCK Clause.
If the MODE IS BLOCK clause is added to an ACCEPT or DISPLAY of a group
item, the group item is treated as if it was an elementary item of the
total size of the group item.
Consider the following group item:
01 display-item.
03 display-item-1 pic x(20).
03 filler pic x(35).
03 display-item-2 pic 9(10).
03 filler pic x(105).
03 display-item-3 pic z(4)9.
If the following statement is executed:
display display-item at 0101 mode is block.
display-item is treated as if it was an elementary item defined as:
01 display-item pic x(175).
Consequently, the contents of the FILLER items are also displayed.
NOTE If a program is compiled with the IBM-MS, MS"1", MS"2" or RM
directives set, the Compiler treats all DISPLAY and ACCEPT
operations of group items as if MODE IS BLOCK had been specified.
Screen Section ACCEPT and DISPLAY Statements
ACCEPT and DISPLAY operations involving Screen Section items are treated
like any other ACCEPT or DISPLAY operation, but with one important
difference. Consider the following code:
working-storage section.
01 item-a pic 9(5).
01 item-b pic 9(10).
01 item-c pic x(10).
...
screen section.
01 demo-screen.
03 blank screen.
03 line 1 column 1 pic z(4)9 from item-a.
03 line 3 column 1 pic 9(10) to item-b.
03 line 5 column 1 pic x(10) using item-c.
When this code is compiled, the compiler sets up a work area for each
Screen Section 01 level item (record). Therefore, in this example, a
work area is set up for demo-screen large enough to hold the data for the
three fields.
When the following statement:
display demo-screen
is executed, the contents of item-a and item-c are moved from
Working-Storage Section into the work area, then the data in the work
area for these two fields is displayed on the screen. item-b is not
displayed because it is an ACCEPT-only field.
When the following statement:
accept demo-screen
is executed, data is accepted into the work area for item-b and item-c
and then the data for these two fields is moved from the work area into
the Working-Storage Section. Data is not accepted into item-a because it
is a DISPLAY-only field.
It is important to note that moves from the Data Division to the work
area occur only on execution of a DISPLAY statement, and moves from the
work area to the Data Division occur only during execution of an ACCEPT
statement. Therefore, if two ACCEPT statements are executed one after
another with no intervening DISPLAY statement, the initial contents of
the fields at the start of the second accept are those which were put
into the work area during the previous ACCEPT operation not the current
contents of the Data Division items.
Another implication of this is that a field should not be defined as
numeric-edited in both the Data Division Section and the Screen Section.
This results in the compiler making numeric-edited to numeric-edited
moves in order to move the Data Division item into the work area and back
again. The action of such moves is undefined and has unpredictable
results. This is the case even if both the Data Division item and the
Screen Section item have the same picture.
Hence, if the following lines are coded in your program:
working-storage section.
01 ws-item pic zz9.99 value 1.23
screen section.
01 demo-screen.
03 pic zz9.99 using ws-item.
procedure division.
display demo-screen.
the result of the DISPLAY operation is undefined. The items used in the
Data Division as source or target for Screen Section ACCEPT or DISPLAY
statements should always be non-edited fields.
The CURSOR IS Clause
This feature allows you to specify precisely where in a field you want
the cursor to be positioned at the start of the ACCEPT operation, and
returns where the cursor was left at the end of an ACCEPT operation. If
you do not specify a CURSOR IS clause in your program, the cursor is
always initially positioned at the start of the first field for every
ACCEPT operation.
The CURSOR IS clause is defined in the Special-Names paragraph , as
follows:
special-names.
cursor is cursor-position.
where cursor-position is a field defined in the Working-Storage Section
of your program as follows:
01 cursor-position.
03 cursor-row pic 99.
03 cursor-column pic 99.
or
01 cursor-position.
03 cursor-row pic 999.
03 cursor-column pic 999.
where:
cursor-row specifies the row the cursor is positioned on. Valid
values are between 1 and the number of lines on the
screen.
cursor-column specifies the column the cursor is positioned on.
Valid values are between 1 and the number of columns
on the screen.
Whenever an ACCEPT statement is executed, Adis attempts to initially
position the cursor at the position specified in cursor-position. If the
position specified is invalid (that is, either cursor-row or
cursor-column does not contain a valid value), the cursor is positioned
at the start of the first field on the screen.
If the value in cursor-position is valid, Adis searches through all of
the fields to see if the requested cursor position lies within one of
them. If it does, the cursor is positioned at the required point. If it
does not, then the cursor is positioned at the start of the first field.
Therefore, if you want the cursor to be positioned at the start of the
first field, set both cursor-row and cursor-column to 1.
Where the defined position is on a suppressed character or insertion
symbol in a numeric edited field, the cursor moves to the first available
character to the right. If there is no further data item, the cursor
returns to the first data item on the screen.
When the ACCEPT is terminated, if the value in cursor-position at the
start of the ACCEPT was valid, the position of the cursor when the
terminating key is pressed is returned in cursor-position. This might
not be the same position as the current cursor position, since Adis
usually moves the cursor to the end of the field upon termination of an
ACCEPT operation to allow relative positioned ACCEPT statements to start
at the correct point on the screen.
If the value in cursor-position at the start of the ACCEPT operation was
invalid, then, when the ACCEPT operation is terminated, the contents of
cursor-position are unchanged.
One example of the use of this facility is that in menu-type operations,
the operator need only move the cursor to a position on the screen
corresponding to the selection required. The operator's choice can be
determined by the returned value of cursor-position.
Large Screens
Screens larger than 25 lines can be detected by your COBOL system.
On DOS, Windows and OS/2, if you link with LCOBOL, large screens are
detected automatically. If you link with COBLIB, you should use the +C
switch at run time. See the appendix Descriptions of Run-time Switches
for more information on the +C switch. (DOS, Windows and OS/2)
On UNIX you can define the screen size in your terminfo entry. Programs
using ANSI ACCEPT/DISPLAYstatements, enhanced ACCEPT/DISPLAY syntax,
Screen Section and the COBOL system library routines should run correctly
on large screens. If an application is developed for a screen larger
than the screen it is run on, the extra lines of a multiple-field ACCEPT
or DISPLAY are lost. In addition, if the position specified by the AT
clause of an ACCEPT or DISPLAY statement is off the screen, the screen is
scrolled up by one line.(UNIX)
Data Division Size
On DOS, Windows and OS/2 environments, all parameters passd to Adis must
be in the first 64K of the Data Division. Consequently, Screen Section
must not exceed 64K and any data items used in Enhanced ACCEPT and
DISPLAY statements that are passed to Adis and any parameters passed to
x"AF" calls must be in the first 64K. (DOS, Windows and OS/2)
Under UNIX environments, the above restriction does not apply, hence this
consideration is for compatibility purposes only. This restriction
should be observed only for intermediate code compiled with the
INTLEVEL"1" Compiler directive. See the appendix Directives for Compiler
for details.(UNIX)