Clark Morris wrote:
You might even make a stink about the lack of
improvements in the language that is supposedly the
one of the future.
Personally, given IBM and other vendor actions,
I believe it is a cash cow on a long term death bed.
At the Tampa Share, I think, Tom Ross announced that he
Tony Harminc wrote:
It's useful to limit the opcodes understood, because the disassembler (any
disassembler for this architecture - not just IBM's) is less than perfect at
understanding what is code and what is data. If you know something about the
module you are working on (typically it is some
The High level Assembler accepts and uses an OPTABLE parm which lets
you limit the valid op codes to an architecture level such as XA or
370 (and optionally list the valid OP codes at that level). The Disassembler
(ASMDASM) has a comparable ÓPTABLE option which Specifies the operation
code table
I'm trying to convert the following
pseudo code to run under COBOL
01 CHAR PIC X(4) VALUE 'CHAR'.
is incorrect. When you define a character value
with a length less than 8 you need a trailing blank:
01 CHAR PIC X(5) VALUE 'CHAR '.
Gene Lynd
Paul Gilmartin asked Is there any way to force
the non-executable attribute on a load module?
File-AID 3.1 can do this. Use option I and
disposition OLD - you can then overtype the
attributes, including EXEC (executable).
Gene Lynd
An unenforced prohibition is meaningless. Not really,
with all due respect to Justice Holmes.
The possibility of future enforcement hangs over my
guilty head. Specifically, I am testing symbolic
parameters in procs, although they are not among the
valid operands. For example:
PROC
6 matches
Mail list logo
