I wanted to close the loop on this, and frankly, vent a little bit.
I played around and played around with different C++ and LE options -- nothing
seemed to make a big difference. So finally I wrote a trivial, 3-machine
instruction, do-nothing ADATA exit in HLASM. It turns out the overhead is
Think generators and iterators.
From: IBM Mainframe Discussion List on behalf of
Rupert Reynolds
Sent: Sunday, July 16, 2023 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ coroutines are recent, and difficult?
Oh I see!
Thanks. Yes, that would
Oh I see!
Thanks. Yes, that would make sense, although from my trivial understanding
it might make coroutines less useful for my kind of work.
Roops
On Sun, 16 Jul 2023, 12:08 Seymour J Metz, wrote:
> With ATTACH, you need to play games to prevent two tasks from running
> concurrently on two
.com/Home/pdf/compiler.pdf>
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, July 16, 2023 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ coroutines are recent,
On Sun, 16 Jul 2023 11:08:51 +, Seymour J Metz wrote:
>With ATTACH, you need to play games to prevent two tasks from running
>concurrently on two CPUs. With coroutines, you have multiples contexts within
>a single thread; there is no need for explicit interlocking.
>
Il a les défauts de ses
With ATTACH, you need to play games to prevent two tasks from running
concurrently on two CPUs. With coroutines, you have multiples contexts within a
single thread; there is no need for explicit interlocking.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
For a bit more information. If I don't include any of my Assembler routines in
the DLL then the binder sets the CEESTART as the entry point. When I do include
any of the Assembler routines, which use EDCPRLG as its entry code, then the
one that ends of first in the sort order of names becomes
, July 11, 2023 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: C DLL abend CEE3350S
I know, but the CEESTART CSECT is included in the program object. On another
DLL, which is just 1 module with multiple functions, the CEESTART CSECT is
listed in the load map
I've already built another DLL successfully, albeit with just 1 module. And we
are doing all this on the z/OS side and not the USS side so those commands are
not available for use.
--
For IBM-MAIN subscribe / signoff / archive
These are the ones that are explicitly set.
LANGLVL(EXTC1X)
LIST
ILP32
DEBUG(LEVEL(9))
AGGREGATE(OFFSETHEX)
NOXPLINK
DLL
In the z/OS dlls that we have built that contain C, C++, and Assembler routines
we don't reference CEESTART *anywhere* in our source tree.
- Did you compile with: -W "c,dll,expo" ?
- We bind our dll with z/OS Unix make using c++ (or c89, xlc) command as
shown in "z/OS XL C/C++ User's
What compiler directives were used?
On Wed, Jul 12, 2023 at 5:18 AM Eric Erickson wrote:
> I know, but the CEESTART CSECT is included in the program object. On
> another DLL, which is just 1 module with multiple functions, the CEESTART
> CSECT is listed in the load map as such.
>
>
>
Do you have an INCLUDE for the CEESTART module? Does LE look for an
eyecatcher that it recognises as CEESTART, not just an ENTRY which as
Seymour says isn't the same.
Take LET off the bind in case there's another hidden problem.
On Wed, Jul 12, 2023 at 5:18 AM Eric Erickson wrote:
> I know,
I know, but the CEESTART CSECT is included in the program object. On another
DLL, which is just 1 module with multiple functions, the CEESTART CSECT is
listed in the load map as such.
0 CEESTART*
There's a difference between an entry point and a csect.
From: IBM Mainframe Discussion List on behalf of
Eric Erickson
Sent: Tuesday, July 11, 2023 2:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: C DLL abend CEE3350S
I've a LE C DLL I've built that
Your laptop I would assume is not an IBM Mainframe
No matter how you specify character constants you have to be aware of the
character set. My big C++ project was "bi-modal": it ran "production" on z/OS
and limited unit test on Windows. I had to be aware of whether I meant 'A" or
0xC1 or 0x41
In EBCDIC world.
I had a hard time, when I ported the Stanford Pascal compiler to
Windows/Unix etc.;
it compiled a Pascal Case statement (which is switch in C and SELECT in
PL/1)
involving char constants as Case labels, and, when building the branch table
(addresses to branch to, depending on
On Thu, 18 Aug 2022 11:13:18 -0500, Charles Mills wrote:
>'A' is just another way of saying 193.
>
My laptop says it's 65.
>'ABC' is just another way of saying 12698307.
>
Even more trouble. 65 or 'A' or 193 works if you understand your application.
--
gil
C provides lots of different ways to shoot yourself in the foot. That's
just one.
On Thu, Aug 18, 2022 at 11:25 AM Kirk Wolf wrote:
> IMO, not a good way.
> According to the standard, the integer value of 'ABC' is implementation
> dependent. The IBM XLC/C++ Language Reference doesn't
IMO, not a good way.
According to the standard, the integer value of 'ABC' is implementation
dependent. The IBM XLC/C++ Language Reference doesn't document how it will
be treated (padding, alignment, etc) as far as I can see.
Kirk Wolf
Dovetailed Technologies, LLC
http://coztoolkit.com
'A' is just another way of saying 193.
'ABC' is just another way of saying 12698307.
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
This is quite natural, given the fact, that char in C is not really a
type in its own right,
but instead a subtype of int, like short (only smaller).
If you keep that in mind, there is simply no difference between char
constants
and int constants.
HTH, kind regards
Bernd
Am 17.08.2022 um
Or putting it differently, which of these do you find problematic and which not?
int foo = 12698307;
int foo = 0xC1C2C3;
int foo = 'ABC';
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
> Can of worms.
No more so that the well-established int foo = 'A';
> Documentation?
I am sure I did not invent the syntax. I saw it somewhere in the docs.
> Portability of e.g. "int foo = 'ABC';":
What about it? Just like the well-established int foo = 'A';
> Blank/null fill?
Just like for
This is one of those rare cases when Gil stays on topic and also I agree
completely ;-)
In the C standards, these are “multi-character integer character constants”
aka multi-chars and resolve to type int.
All of the issues that Gil points out are "implementation dependent"
Kirk Wolf
On Wed, 17 Aug 2022 13:30:09 -0500, Charles Mills wrote:
>> Some C compilers allow longer character constants
>
>It is an option for the IBM XLC compiler. I will leave looking up the specific
>option as an exercise for the reader.
>
>I recall beyond a shadow of a doubt that on the XLC compiler
> Some C compilers allow longer character constants
It is an option for the IBM XLC compiler. I will leave looking up the specific
option as an exercise for the reader.
I recall beyond a shadow of a doubt that on the XLC compiler for Z I have used
int foo = 'ABCD';
Charles
On Wed, 17 Aug 2022 14:48:27 +, Seymour J Metz wrote:
>Unlike PL/I, C treats characters and strings differently. C uses apostrophes
>for character constants, which are limited to single characters, either
>explicitly or due to a backslash (\) escape sequence. IMHO the message should
>be an
On Wed, Aug 17, 2022 at 10:16:17AM +0300, Binyamin Dissen wrote:
> I have inherited some C code.
>
> str2 = str2 ¦ 'xF0';
> str1 = str1 >> 4;
> str1 = str1 ¦ 'xF0';
>
> These receive
>
> CCN4118 Character constant 'xF0' has more than 1
Unlike PL/I, C treats characters and strings differently. C uses apostrophes
for character constants, which are limited to single characters, either
explicitly or due to a backslash (\) escape sequence. IMHO the message should
be an error, not a warning.
--
Shmuel (Seymour J.) Metz
Interesting.
So the code actually works.
On Wed, 17 Aug 2022 11:24:31 +0100 Colin Paice wrote:
:> :>>SLR r0,r0 clear
:>register 2
:>:>>IC r0,str2(,r13,157) load the one
:>character into it
:>:>>
In C, char constants are syntactically the same as int constants.
You have two choices to write hex int or char constants:
the "int" flavor: 0xf0
the "char" flavor: '\xf0'
or simply 240
or (this is ill-fated IMO) 0360 ...
because a leading zero makes the number an octal number in C
So,
:>>SLR r0,r0 clear
register 2
:>>IC r0,str2(,r13,157) load the one
character into it
:>>Or0,=F'10995440' OR this with
0x00A7C6F0' (=F'10995440') which is a7=x
Quite possible.
To confirm, it is '\xf0' with surrounding quotes of \xF0 without quotes. Or
both?
On Wed, 17 Aug 2022 09:31:18 +0200 Bernd Oppolzer
wrote:
:>Could it be that the source has been transferred in any way?
:>
:>It would be valid, if there was a backslash before the hex constant,
Could it be that the source has been transferred in any way?
It would be valid, if there was a backslash before the hex constant,
like below;
backslash, followed by x, followed by two hex digits is a single char in C.
str2 = str2 ¦ '\xF0';
HTH, kind regards
Bernd
Am 17.08.2022 um 09:16
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Thursday, October 21, 2021 8:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C signal() and abends not being signaled
You're using the wrong signal. SIGABND catches abends
: Re: C signal() and abends not being signaled
You're using the wrong signal. SIGABND catches abends such as x37. If
you want to catch machine checks use SIGSEGV (0C4), SIGILL (0C1) etc.
On 19/10/2021 11:03 pm, Jantje. wrote:
> Esteemed listers,
>
> I have the situation that in the vast
On 22/10/2021 5:18 pm, Jantje. wrote:
That said, as @Joe says, the C signal handling is not real conducive to "make note
of the problem and continue on where you were" processing.
O, and returning from the signal handler does indeed resume processing after
the instruction that caused the
On Tue, 19 Oct 2021 09:13:09 -0700, Charles Mills wrote:
>I have a lot of experience with catching signals in a "conventional MVS"
>started task written in C++. (Signal handling is a C function but also
>available in C++.) In my experience the signal handler was perfect at catching
>S0C4 type
You will also want TRAP(OFF) in your LE options otherwise LE will always
intercept any abend.
Robin
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Crayford
Sent: 22 October 2021 07:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C signal() and abends not being
You're using the wrong signal. SIGABND catches abends such as x37. If
you want to catch machine checks use SIGSEGV (0C4), SIGILL (0C1) etc.
On 19/10/2021 11:03 pm, Jantje. wrote:
Esteemed listers,
I have the situation that in the vast majority of cases the C program just
works fine, but in
I have a lot of experience with catching signals in a "conventional MVS"
started task written in C++. (Signal handling is a C function but also
available in C++.) In my experience the signal handler was perfect at catching
S0C4 type exceptions with SIGSEGV.
That said, as @Joe says, the C
"When the SIGABND signal is registered with an address of a C handler using
the signal() function, control cannot resume at the instruction following
the abend or the invocation of raise() with SIGABND. If the C signal
handler is returned, the abend is percolated and the default behavior
occurs.
* #define PIPE_BUF
*/
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Thursday, December 3, 2020 5:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C macro for maximum path length?
PATH_MAX on
On Fri, 4 Dec 2020 09:25:07 -0800, Charles Mills wrote:
>@Gil, weren't you going to try a mkdir wombat/cd wombat endless loop and see
>where it failed?
>
My latest attempt:
# ###
#! /bin/sh
# Doc: Test limits of path length (PATH_MAX)
# and directory nesting
ERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, December 4, 2020 7:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C macro for maximum path length?
It would be a courtesy to leave a citation when appending to a thread.
A reader might wish to refer to the ped text.
On Fri, 4 Dec 2020 08:1
It would be a courtesy to leave a citation when appending to a thread.
A reader might wish to refer to the ped text.
On Fri, 4 Dec 2020 08:19:34 -0500, Peter Relson wrote:
>
>The real question is not "how long can a path be [today]?" but rather "how
>long might a path be at any future point
The real question is not "how long can a path be [today]?" but rather "how
long might a path be at any future point when this compilation is
running?"
And that's why z/OS will never change the maximum path length by default
(I actually thought it was 1024, but my knowledge is only from what
eading the doc leads me to think it is
> an FTP limit, not a z/OS limit.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: Thursday, December 3, 2020 3:26 PM
> To: IB
@LISTSERV.UA.EDU
Subject: Re: C macro for maximum path length?
Sorry, here is the error message.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cs3cod0/ftp550113.htm
z/OS Unix System Services specifies the maximum file name of 255 and
path of 1023.
https://www.ibm.com
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Thursday, December 3, 2020 9:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C macro for maximum path length?
>
> Thanks @Gord, yes, I saw pathconf().
>
> I am starting to
s conundrum?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Thursday, December 3, 2020 9:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C macro for maximum path len
Subject: Re: C macro for maximum path length?
Thanks @Gord, yes, I saw pathconf().
I am starting to "get" the problem.
> I suspect there's a buffer overrun hazard associated with a statically
> compiled
> PATH_MAX.
Never mind the exact lack of a macro and never mind z/OS.
t;work buffer" was kind of a lazy programmer approach.
Thanks all for your patience and explanations.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Thursday, December 3, 2020 9:08 AM
To: IBM-MAIN@LISTSER
On Thu, 3 Dec 2020 11:49:05 -0500, Gord Tomlin wrote:
>On 2020-12-03 10:12 AM, Charles Mills wrote:
>> I believe you, but why then is the macro undefined? Why is the definition
>> now commented out?
>>
I suspect there's a buffer overrun hazard associated with a statically compiled
PATH_MAX.
On 2020-12-03 10:12 AM, Charles Mills wrote:
I believe you, but why then is the macro undefined? Why is the definition now
commented out?
>From (actually CEE.SCEEH.H(LIMITS)) on z/OS V2R4:
/*
* POSIX.1 1990 Section 2.8.5 Statement 1065 -
* these macros "shall be omitted on specific
*
#define PIPE_BUF
*/
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Thursday, December 3, 2020 5:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C macro
PATH_MAX on z/OS is 1023. This is documented in lots of error messages and BPX
assembler services.
> On 3 Dec 2020, at 7:16 am, Charles Mills wrote:
>
> I have some code that compiles both under Windows Visual Studio and z/OS
> XLC.
>
> In Windows the maximum length of a file path is
On Wed, 2 Dec 2020 16:43:11 -0800, Charles Mills wrote:
>This code has been changed since I last compiled it on Z but I don't think I
>changed that reference. It appears that PATH_MAX went away somewhere between
>V2R2 and V2R4. I see some comments in limits.h that are consistent with that.
>
@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, December 2, 2020 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C macro for maximum path length?
On Wed, 2 Dec 2020 15:16:10 -0800, Charles Mills wrote:
>I have some code that compiles both under Windows Visual Studio and z/OS
>XLC.
>
&g
On Wed, 2 Dec 2020 15:16:10 -0800, Charles Mills wrote:
>I have some code that compiles both under Windows Visual Studio and z/OS
>XLC.
>
>In Windows the maximum length of a file path is defined by _MAX_PATH and
>__MAX_PATH (I guess MS thinks two macros are better than one).
>
>What is the
Kirk Wolf wrote:
Can be demonstrated with the following test program. This works fine with
regcomp() on linux and other RE platforms (PCRE, javascript, python, etc).
I dunno why that would fail - tried it with a couple of UNIXs
and of course Dignus Systems/C, all got return-code of 0.
On Mon, 5 Oct 2020 10:40:30 -0500, Kirk Wolf wrote:
>
>/* test regcomp with more than 9 (groups).
> On z/OS V2R3, fails with:
> Invalid regular expression '...' - (rc=8) \( \) or ( ) imbalance
>...
>Switching to BREs, doesn't help. Something probably didn't fit in 80 bytes
>:-)
Perhaps
No problem with the line length. It's regcomp() that seems broken.
I believe that this is the version of the Open Group spec that IBM is
supposed to be supporting, which mentions no limit on the number of groups
(aka "subexpressions").
https://pubs.opengroup.org/onlinepubs/009695399/
On Mon,
One of C's less frequently used features is automatic string literal
concatenation. The expression
"AB" "cd"
will be compiled as
"ABcd"
as long as the components (could be more than two) are separated only by white
space.
So if the problem really is related to line length (your
It's been awhile. Think there was a set distributed with SDSF. Don't know if it
was IUP or feature. Mid 80's got to debug somebody's production application
that corrupted their TMC. Only took half the night.
In a message dated 4/29/2020 10:32:04 PM Central Standard Time, jcew...@acm.org
Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Joel C. Ewing [jcew...@acm.org]
Sent: Wednesday, April 29, 2020 7:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
I think many places had various forms of structured macros for Assembler
during the 1980's. I believe there was eventually even a set
Sunday, April 26, 2020 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C
>
> EXTERNAL EMAIL
>
>
>
>
>
> I was doing an internship in the Chicago area during the summer of 1984.
> They were using an assembler with IF macros.
>
> On Sun, Apr 26, 2020 at 2:11 PM
own.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Sunday, April 26, 2020 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
EXTERNAL EMAIL
I was doing an internship in the Chicago area during the summer of 1984. They
were using
@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Monday, April 27, 2020 10:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
Absolutely it was true. The printer could release the Mux channel while it
advanced the carriage. This was the old days. Not a lot of intelligence in a
printer
0 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
Doesn't seem right to me. If we're takling ANSI carriage control.
0 - move double
blank - move single
+ - no LF
1 - Skip to next page (Channel 1)
We always used machine code characters because they didn't have to be
immediate whereas ANSI were
Gilmartin
Sent: Monday, April 27, 2020 7:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
On Tue, 28 Apr 2020 11:47:23 +1000, Wayne Bickerdike wrote:
>Doesn't seem right to me. If we're takling ANSI carriage control.
>
I think they're talking MVT COBOL syntax.
>0 - move double
>blank -
On Tue, 28 Apr 2020 11:47:23 +1000, Wayne Bickerdike wrote:
>Doesn't seem right to me. If we're takling ANSI carriage control.
>
I think they're talking MVT COBOL syntax.
>0 - move double
>blank - move single
>+ - no LF
>1 - Skip to next page (Channel 1)
>
>We always used machine code characters
pliant.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joe Monk [joemon...@gmail.com]
> Sent: Monday, April 27, 2020 3:31 PM
> To: IB
[joemon...@gmail.com]
Sent: Monday, April 27, 2020 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
Not according to the MVT Cobol compiler manual...
"The AFTER ADVANCING option is used for output destined to be printed or
punched. When this option is used, the first character in each lo
t; http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
> Sent: Monday, April 27, 2020 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C
>
ms, but useful when migrating from OS/VS COBOL.
From: IBM Mainframe Discussion List on behalf of
Seymour J Metz
Sent: Monday, April 27, 2020 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
That's a bug; the carriage control character is supposed to
[000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, April 27, 2020 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
On Mon, 27 Apr 2020 15:06:03 +1000, Wayne Bickerdike wrote:
>
>I had neither mainframe COBOL nor SPPS skills but I'd written a whole bunch
>of Microfocus COBO
On Mon, 27 Apr 2020 15:06:03 +1000, Wayne Bickerdike wrote:
>
>I had neither mainframe COBOL nor SPPS skills but I'd written a whole bunch
>of Microfocus COBOL on CP/M micros.
>
>I convinced them that I could do mainframe COBOL, which wasn't that
>difficult. When I looked at the SPPS code, it was
ent: Monday, April 27, 2020 1:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
Seymour,
The assembler was SPPS. Too close to the stats package name SPSS.
I was working at a DOS/VSE shop in England in 1983 and they had COBOL and
SPPS on their IBM cash registers.
I had neither mainframe COBOL nor S
tatistical Package for the Social
>> Sciences, and it didn't look like assembler.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] o
hmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Wayne Bickerdike [wayn...@gmail.com]
> Sent: Sunday, April 26, 2020 4:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
>
M-MAIN@LISTSERV.UA.EDU] on behalf of
Wayne Bickerdike [wayn...@gmail.com]
Sent: Sunday, April 26, 2020 4:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
I thought the macros were part of CONCEPT 14? I do remember working on IBM
3684 point of sale systems between 1982 and 1986. They were programmed
, but they didn't come from IBM.
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> http://mason.gmu.edu/~smetz3
> >>
> >>
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV
on List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
>> of Mike Schwab [mike.a.sch...@gmail.com]
>> Sent: Sunday, April 26, 2020 1:25 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: C
>>
>> I was doing an internship in the Chicago area during the summer of
>>
://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Mike Schwab [mike.a.sch...@gmail.com]
> Sent: Sunday, April 26, 2020 1:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C
>
> I was doing an internship in the C
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Sunday, April 26, 2020 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C
I was doing an internship in the Chicago area during the summer of
1984. They were using
I was doing an internship in the Chicago area during the summer of
1984. They were using an assembler with IF macros.
On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote:
>
> HLASM in 1980? Not before June 1992. I assume that you were using XF and H,
> possibly with the SLAC mods on the
HLASM in 1980? Not before June 1992. I assume that you were using XF and H,
possibly with the SLAC mods on the latter (thank you, Greg and John.)
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
On 2020-01-30 6:35 AM, Charles Mills wrote:
I suppose if someone REALLY wanted to be a C++ pedant,
myStruct *opts_char = reinterpret_cast(reinterpret_cast(opts));
haha! that's what I would code but in reality a reinterpret_cast is a
raw cast so it doesn't matter. It's a style thing
so you
lol. You might be a Programming Geek if "code still works" is a "side
benefit".
sas
On Wed, Jan 29, 2020 at 5:35 PM Charles Mills wrote:
> You're a genius! Thanks. Message is gone, and as a side benefit, the code
> still works.
y, January 29, 2020 2:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ reinterpret_cast question
You're a genius! Thanks. Message is gone, and as a side benefit, the code still
works.
I suppose if someone REALLY wanted to be a C++ pedant,
myStruct *opts_char = reinterpret_cast(reinterpret
rles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Gord Tomlin
Sent: Wednesday, January 29, 2020 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ reinterpret_cast question
On 2020-01-29 13:29, Charles Mills wrote:
> If you're n
MAIN@LISTSERV.UA.EDU] On Behalf
Of Allan Kielstra
Sent: Wednesday, January 29, 2020 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ reinterpret_cast question
Also, I trust that you know what you're doing! Depending on the
implementation of C++, a pointer to a function can sometimes be a po
Hmmm.
V2R2
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Allan Kielstra
Sent: Wednesday, January 29, 2020 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ reinterpret_cast question
FWIW, you don't get this warning
Also, I trust that you know what you're doing! Depending on the
implementation of C++, a pointer to a function can sometimes be a pointer to a
function descriptor. So be careful with what you do with opts_char. (But you
say that the resulting code basically works so that is good.)
Also, on
FWIW, you don't get this warning with 2.4.1 (or 2.3.1). What version are you
using?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Microsoft Visual C has #pragma warning (disable : ) dint know about XL C
> On Jan 29, 2020, at 1:29 PM, Charles Mills wrote:
>
> If you're not a C++ person you may hit Delete at any time ...
>
> I want to load a module that is a non-executable table (and non-reentrant)
> and then
On 2020-01-29 13:29, Charles Mills wrote:
If you're not a C++ person you may hit Delete at any time ...
I want to load a module that is a non-executable table (and non-reentrant)
and then modify it.
I have the entry point declared as
extern "OS" typedef int compiler_t(void *parm1);
compiler_t
When Pascal is mentioned in this Mainframe related mailing list,
this triggers me, of course.
I am the current maintainer of the New Stanford Pascal compiler,
which runs on MVS, VM (and on Windows, OS/2, Linux, MacOS, BTW)
and on modern z/OS (and probably z/VM), too ... although limited to
AMODE
1 - 100 of 434 matches
Mail list logo
