HP 3000 Manuals HP 3000 Manuals
Conversion Issues
Most of the Microsoft COBOL Version 2.2 programs which you submit to this
COBOL system will be accepted syntactically and will run successfully.
However, incompatibilities may occur in a number of areas.
In some minor cases, this COBOL system will produce errors when
encountering missing periods or spelling errors (for example, SOURCE
COMPUTER in place of SOURCE-COMPUTER is not acceptable).
The sections below detail the known features which could produce errors,
or which may not behave in the way you expect, along with hints on how to
rectify the cause of such errors, or emulate the behavior of Microsoft
COBOL Version 2.2 programs.
General
Source Code Beyond Column 72.
This condition occurs if the standard TAB settings on the Microsoft COBOL
Version 2.2 Compiler have been changed either by patching the run-time
system, or by using the /O directive.
Solution.
Before submitting your Microsoft COBOL Version 2.2 program to this COBOL
system, process the program with the tabx utility (see the chapter
Converting an RM/COBOL Application in the Conversion Series 3 Part for
details of how to do this). This expands any tab characters into spaces.
You can then successfully submit your source programs to this COBOL
system.
COBOL Concepts
COMP-3 Sign Representation.
Under this COBOL system, unsigned COMP-3 fields produce different sign
representation from that of Microsoft COBOL Version 2.2.
Solution.
You must ensure that you specify the MS"2"system directive which will
cause unsigned COMP-3 fields to be treated in the same way as they were
under Microsoft COBOL Version 2.2: that is, as signed positive. This
directive is automatically set by the Setup utility if you select the
Microsoft Version 2.2 option.
Declaratives.
Any declaratives statement which appears after a paragraph header is
rejected when you submit your program to this COBOL system.
Solution.
This COBOL system insists that the declaratives statement immediately
follows the section header, rather than the paragraph header. Amend your
source program and resubmit it to this COBOL system.
The Nucleus
Special-Names Paragraphs.
You may receive an error on the SPECIAL-NAMES paragraph header when you
submit your program to this COBOL system.
Solution.
When you submit your program to this COBOL system, ensure that the
SPECIAL-NAMES paragraph is inside the Environment Division.
The EJECT Statement.
The EJECT IS...statement in the SPECIAL-NAMES paragraph is rejected when
you submit your program to this COBOL system.
Solution.
Replace the word EJECT with the word FORMFEED.
PICTURE Strings.
Items with PICTURE clauses such as "-.ZZ" may produce errors when you
submit your program to this COBOL system.
Solution.
If you receive errors for picture-strings which contain a "-" (minus)
followed by a ". " (period), or a ". " followed by a "Z", either alter
the "Z" characters to "?" characters, or add a BLANK WHEN ZERO clause.
The SEGMENT-LIMIT Clause.
The SEGMENT-LIMIT IS...clause is treated as documentary by this COBOL
system, although this should not produce any problems. However,
segmentation is an out-dated feature of COBOL and is treated by the ANSI
standard as an obsolete feature.
The REDEFINES Clause.
Certain usage of the REDEFINES clause in a Microsoft COBOL Version 2.2
program will produce errors when you submit your program to this COBOL
system. For example:
03 A.
...
03 B.
...
03 C REDEFINES A.
is not accepted by this COBOL system because C is not the next item of
the same level after A.
Solution.
In the above example, move the redefinition so that it is the next item
of the same level, after the item it is redefining.
The VALUE Clause.
A VALUE clause on an INDEXdata item will produce errors when you submit
your program to this COBOL system.
Solution.
Remove the VALUE clause and use the SET statement
at the start of the Procedure Division to supply an initial value to the
INDEX data item.
File Input and Output
File-names.
Incorrect file-names are being used by programs when you run them under
this COBOL system.
Solution.
All file-names under this COBOL system must be terminated by a space,
whereas under Microsoft COBOL Version 2.2, a file-name must be terminated
by a null byte.
OPEN...EXTEND.
When opening a nonexistent file EXTEND, this COBOL system, unlike
Microsoft COBOL Version 2.2, does not create the file.
Solution.
You can solve this by placing the word OPTIONAL
after the word SELECT for this file.
Record Locking.
* The WAIT clauseon a READ statement
behaves differently on the two systems, in that the WAIT clause is
actually ignored by this COBOL system. Instead the file status
item will be updated to indicate that a record is locked.
Solution.
Check for the `Record locked' status and loop back to re-read the record.
* Locking syntax is ignored in the START statement
under this COBOL system.
Solution.
Alter these statements and move the appropriate locking semantics to the
SELECT statementand OPEN or READ statements for the file in question.
Deleting Relative Records.
Records in a relative file are not deleted by this COBOL system if they
are rewritten with the first byte containing LOW-VALUES.
Solution.
In accordance with the warning in the Microsoft manual, we recommend that
you do not use this feature of the Microsoft COBOL Version 2.2 system,
but if you have used it, you should be able to replace the relevant
program logic with a simple DELETE statement.
Rebuild.
The current version of Rebuild does not allow you to reorganize files so
that the keys are in descending order.
Solution.
If any of your programs rely on this ordering of the records, it can be
simulated by first positioning on the last record in the file (using a
START statementwith HIGH-VALUES in the key) and then using the READ
PREVIOUS syntax.
NOTE To enable the READ PREVIOUS syntax, you must specify the
MF"3"system directive, although when you do, it enables some other
reserved words. See your Language Reference for details of these
reserved words.
Debug
TRACE Statements.
The READY TRACE and RESET TRACE statements do not have any effect under
this COBOL system.
Solution.
You should specify the directive TRACE when you submit your program to
this COBOL system and these statements will function correctly.
Inter-Program Communication
The ON OVERFLOW Phrase.
Under this COBOL system, when a subprogram is not found, an ON OVERFLOW
phrase on the CALL statement does not cause the program to stop with an
error. Instead, the ON OVERFLOW path is followed if the subprogram is
not found (and also if there is insufficient memory).
Solution.
It is very unlikely that any application is relying on a program to stop
with a fatal error. However, if this is the case, you should change the
logic in the ON OVERFLOW phrase to handle this.
NOTE An error made when coding the program-name may cause the ON
OVERFLOW phrase to be followed rather than stopping: this is
something of which you should be aware.
Screen Handling
Accepting into Numeric Fields.
Integer numeric fields are accepted differently because numeric edited
fields insert digits from right to left under this COBOL system.
Solution.
Change the picture-string on this COBOL system from 9(n)
to Z(n) and the insertion behavior will be the same as under Microsoft
COBOL Version 2.2.
NOTE Numeric operations cannot be performed on a numeric edited field.
If you do wish to perform numeric operations on this item, you must
move it to a numeric item.
Accepting into Alphabetic Fields.
Alphabetic fields do not allow non-alphabetic characters to be accepted
into them under this COBOL system.
Solution.
Change the PIC A(n) of the field in question to PIC X(n).
Numeric edited Items.
The Screen Sectionsyntax, numeric-edited-item FROM group-item, does not
convert to edited format under this COBOL system.
Solution.
Make the object of the FROM phrase an elementary numeric item and
redefine it if the individual components are required.
Incorrect Spacing.
The Screen Section clause COLUMN PLUS 1does not give the correct
intervening space under some circumstances. For example, the lines:
02 line 1 column 1 ....
02 column plus 1 ....
will not put a space in column 2.
Solution.
You should include an explicit LINE clause in the line in error. For
example:
02 line 1 column 1 ....
02 line 1 column plus 1 ....
Clearing the Screen.
Under this COBOL system, your Microsoft COBOL Version 2.2 programs do not
clear the screen automatically at the start of a run.
Solution.
If you want this to happen, you can insert the statement:
call x"e4"
at the start of the Procedure Division.
Screen Scrolling.
The screen is sometimes scrolled when a program terminates. This happens
only if the cursor is on the last line of the screen when the STOP RUN
statement is obeyed, and is caused by a request for the operating system
prompt.
Solution.
Simply include the following CALL statement immediately before the STOP
RUN statement to position the cursor away from the last line:
call x"e6" using result, parameter
For details of this subroutine, see your COBOL System Reference.
Sounding the Bell.
When you try to sound the bell by displaying an item containing
hexadecimal 7, under this COBOL system, a diamond appears on the screen
instead. This is because the functionality of the ACCEPT/DISPLAY module
has been changed (and considerably enhanced) in this COBOL system.
Solution.
To sound the bell, change this DISPLAY statement in your source program
to the statement:
call x"e5"
Extension Subroutines.
The following Microsoft COBOL Version 2.2 extension subroutines have been
implemented in a slightly different way in this COBOL system:
EXIST
RENAME
REMOVE
COMMAND
UPCASE
LOCASE
EXCODE
KBDAVAIL
CURPOS
To avoid a possible clash with other dialects, the subroutine-names have
been prefaced with _MS (underscore MS), and the length of parameters must
be passed to the routines (this is performed by the LENGTH OF syntax).
Therefore, the subroutine:
call "EXIST" using file-name, status
should become:
call "_MSEXIST" using file-name, LENGTH OF file-name, status
the subroutine:
call "_RENAME"_ using old-file-name, new-file-name, status
should become:
call "_MSRENAME"_ using
old-file-name, LENGTH OF old-file-name,
new-file-name, LENGTH OF new-file-name, status
the subroutine:
call "REMOVE" using file-name, status
should become:
call "_MSREMOVE"_ using
file-name, LENGTH OF file-name, status
the subroutine:
call "COMMAND" using command-line
should become:
call "_MSCOMMAND"_ using
command-line, LENGTH OF command-line
the subroutine:
call "UPCASE" using data-name,
number-of-chars-to-convert, status
should become:
call "_MSUPCASE" using
data-name, LENGTH OF data-name,
number-of-chars-to-convert,
LENGTH OF number-of-chars-to-convert, status
the subroutine:
call "LOCASE" using data-name, number-of-chars-to-convert, status
should become:
call "_MSLOCASE" using
data-name, LENGTH OF data-name, number-of-chars-to-convert,
LENGTH OF number-of-chars-to-convert, status
the subroutine:
call "EXCODE" using exit-code
should become:
call "_MSEXCODE"using exit-code, LENGTH OF exit-code
the subroutine:
call "KBDAVAIL" using status
should become:
call "_MSKBDAVAIL" using status
and the subroutine:
call "CURPOS" using line-number, column-number
should become:
call "_MSCURPOS" using line-number, column-number
The LENGTH OF syntaxused in the way indicated here will produce a Warning
level error message. This message will appear only if you set the
warning level to 2 or 3 using the WARNING directive. The message can be
ignored.