On 10 January 2012 17:33, John Gilmore johnwgilmore0...@gmail.com wrote:
Mr Hall should give us some examples of operations that he judges
awkward or infelicitous done in 'whole register at a time fashion'.
Certainly. But preferably not under the title Conditional assembly for COBOL?.
Tony H.
@LISTSERV.UGA.EDU
Subject: Re: Conditional assembly for COBOL?
IBM Mainframe Assembler List ASSEMBLER-LIST@listserv.uga.edu wrote on
11/22/2011 05:26:36 PM:
I feel the same way about the ESEA instruction.
Trigraphs are the wrong
answer to a question that should never have been asked. (IMO, only
IBM Mainframe Assembler List ASSEMBLER-LIST@listserv.uga.edu wrote on
01/10/2012 03:11:25 PM:
The intent of my post was that it would be a lead-in to a more
generalized discussion as to why it might be that System/360 was
designed with a set of registers that contain heterogeneous control
Keven Hall wrote that he wanted to promote a discussion of
begin snippet
. . . why it might be that System/360 was designed with a set of
registers that contain heterogeneous control information, sometimes
within a single register and yet provides
instructions for loading and storing their values
I will be out of the office beginning until Monday, Nov 28, 2011.
to mis-interpret
my (apparently misguided) attempt at humour.
Shane ...
Begin forwarded message:
Date: Wed, 23 Nov 2011 10:44:56 -0500
From: John Gilmore johnwgilmore0...@gmail.com
To: ibm-m...@bama.ua.edu
Newsgroups: bit.listserv.ibm-main
Subject: Re: Conditional assembly for COBOL?
Jim Mulder
On 11/21/2011 16:07, Patrick Roehl wrote:
I realize this thread has drifted quite a distance from Assembler as a
topic, but hoped to continue the thread until completed.
Naturally there was a snag using the C pre-processor with COBOL syntax.
One line of code in the first source module attempted
MOVE '??' TO QPE-SET-OPTS
Resulted in
MOVE ' TO QPE-SET-OPTS
Can you disable trigraph processing?
-- gil
Disabling trigraph processing indeed solved the source file molestation!
To get trigraph processing disabled required the LANG(COMMONC) option,
which only works with a standard C
PL/I Preprocessor output can be saved in a file, It's a compiler option.
Your example could be done like this:-
%seta: procedure (a1, a2);
declare (a1, a2) character;
answer ('SET ADDRESS OF ' || a1 || ' TO ' );
answer ('ADDRESS OF ' || a2 );
%end seta;
%activate seta;
I don't know
On 11/21/2011 17:36, Patrick Roehl wrote:
MOVE '??' TO QPE-SET-OPTS
Resulted in
MOVE ' TO QPE-SET-OPTS
Disabling trigraph processing indeed solved the source file molestation!
The incriminating evidence is the ??. Trigraphs are the wrong answer
to a question that should never have been
Patrick,
so that it would work on either z/OS or VSE.
If that is the underlying problem...Here is how I do it:
Develop (use any editor but first version is) on the weaker of the
two (in 99.99% VSE). That way you will have solutions for whatever
comes up in z/OS.
What remains are the realy
Oh forgot to add- I do have a preprocessor on both op-sys.
I use .. to trigger calculation/insertation of the length of the next
tic delimited string.
Sample:
06PIC X(..) 'this is message text'.
or
ADD .. to current-length-of-text
STRING 'this is some more' delimited by size
Original Message From: Tom Marchant
An alternate method could be to direct SYSPUNCH to a temporary data set,
which is then used as input to a later Cobol compile step. John's method
has the benefit of greater flexibility to, for example, include additional
steps such as other pre-compilers or
All
Correction. The line counts shown in prior message were total bytes not
lines. The structured conditional macro assembler version of ZSTRMAC.MLC
was exactly 1,000 lines. The bootstrap version in HLASM basic conditional
macro assembler with all the AGO's and macro statement labels is 1,933.
On Nov 17, 2011, at 14:35, Bernd Oppolzer wrote:
The PL/1 preprocessor is IMHO the most powerful tool to do such things,
but maybe you don't have it, if you have no PL/1 licensed.
The ASSEMBLER macro processor will not work, because you cannot
extract the result and send it to the COBOL
-Original Message-
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
snip
Or use existing art:
http://en.wikipedia.org/wiki/M4_%28computer_language%29
-- gil
Oh, that's just __nasty__. m4 is complicated. And, in z/OS, is
OK, just answer me one question.
If you have to use REXX anyway, why not use it for everything?
You guys are making this harder than it really is because of your bias
toward Assembler. (Of course, this is the Assembler List.)
I keep seeing this code and that code to perform the pre-process.
On 18/11/2011 04:29 AM, Patrick Roehl wrote:
I’d like to be able to build various versions of a COBOL program by doing
something like a conditional assembly. Has anyone does anything like this?
Is it possible to add AIF statements to non-assembler source, “assemble
it,� and get the
Hoist by my own new automation again!
The following, which should have been sent here, was in fact sent to IBM-MAIN:
What you propose has been done often.
The HLASM has two assembler operations:
o PUNCH, for which text may contain set symbols, the current values of which are
substituted into
Don't know how to do it with HLASM. But you can run almost anything through the
C preprocessor and have it produce an output deck to pass on to another step.
I'm not sure if you can run the C preprocessor without having C licensed or
not. No, I've not tried it in z/OS.
--
John McKown
Systems
Personally, I would do it with REXX.
Tony Thigpen
-Original Message -
From: Patrick Roehl
Sent: 11/17/2011 12:29 PM
I’d like to be able to build various versions of a COBOL program by doing
something like a conditional assembly. Has anyone does anything like this?
Is it possible
If you want to do this in a procedural language use the PL/I
preprocessor, compared to which the C preprocessor is unseriös.
Anyone who knows REXX, a PL/I dialect, will find it easy to use; and
its string-processing facilities are very powerful, almost as powerful
as those of PL/I proper.
That
The PL/1 preprocessor is IMHO the most powerful tool to do such things,
but maybe you don't have it, if you have no PL/1 licensed.
The ASSEMBLER macro processor will not work, because you cannot
extract the result and send it to the COBOL compiler, AFAIK.
The C preprocessor would work, if you
23 matches
Mail list logo
