Well we do not want to have to check to see if things are changed every time
we leave the building. We have more than enough to do as it is.
John T. Abell
President
International Software Products
Tel: 800-295-7608 Ext: 224
International: 1-416-593-5578 Ext: 224
Fax: 800-295-7609
International: 1-416-593-5579
E-mail: john.ab...@intnlsoftwareproducts.com
Web: www.ispinfo.com
This email may contain confidential and privileged material for the sole use
of the intended recipient(s). Any review, use, retention, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient),
please contact the sender by reply email and delete all copies of this
message. Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive
emails on the basis that we are not liable for any such corruption,
interception, tampering, amendment or viruses or any consequence thereof.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Tuesday, April 01, 2014 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
of course, all those problems are easily solved when coding some small
ASSEMBLER subprograms. I did this in fact, when we had some problems in the
past with the 0C8 abends due to high order bits set in passed addresses
(call an ASSEMBLER subprogram to switch OFF the PSW mask bit for 0C8 on
entry to the C module - which the site wanted to be ON in the normal case -
and switch it ON again, when leaving the C module).
The solution with ASSEMBLER subprograms of course has the drawback that you
have to link the subprogram, that is, you have some impact on the compile
and link JCL, which is not always desirable, and: you have to provide at
least minimal linkage conventions, while a C solution, as I provided it in
my other post, can be inlined in the generated C code without this overhead.
The key is indeed, as Andrew Rowley pointed it out: if you don't tell the C
compiler that the pointer coming from PL/1 is a pointer, the C compiler will
not treat it as a 31 bit value, so you can manipulate it before casting it
to a pointer ... at least I hope so. I see no reason, why the solution
proposed by Andrew should not work.
Kind regards
Bernd
Am 01.04.2014 16:44, schrieb Charles Mills:
> Perhaps write the cleanup function in assembler? This is obviously a
> trivial problem in assembler. None of the inconvenience of strong
> typing to get in your way LOL.
>
> Charles
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
