I still do not know how to make PL/I communicate with C, but COBOL and
C communicate like a pair of newlyweds once this was resolved.
ZA,
Chapter 8 and 9 from this manual might help you. Sample programs in
section 8.9 and 9.8 might be what you are looking at.
Obviously, I know that and I realized that the issue is integral boundaries!
I am dealing with COBOL, not PL/I but the real issue was that the order is the
other way around (i.e. the fullword is first and the halfword is second,
leaving a two bytes gap unaccounted for after every pair.
So I
On Mon, 23 Feb 2015 12:15:09 -0600, Ze'ev Atlas zatl...@yahoo.com wrote:
So I resolved it by adding a dummy two bytes variable in the end of each pair:
10 A PIC 9(9) COMP-5.
10 B PIC 9(4) COMP-5.
10 FILLER PIC XX.=== compensating for the integral boundary of the next
pair
You might want to
Ze'ev Atlas wrote:
Obviously, I know that and I realized that the issue is integral boundaries!
So I resolved it by adding a dummy two bytes variable in the end of each pair:
10 A PIC 9(9) COMP-5.
What are you doing to ensure that A starts on a full word? In other words, what
is declared
I guess I will use SYNC to ensure all integral boundaries... next release :)
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The SYNCHRONIZED clause is new to me (I do not code COBOL on regular basis any
more.) I will incorporate that in the next release.
Thanks to all who had suggested it
ZA
--
For IBM-MAIN subscribe / signoff / archive access
Thanks Kolusu
I will look into the PL/I interface for both this and the PCRE... maybe next
release
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
To give you an example on the different alignment strategy of (for example)
PL/1 and C:
let's assume a structure
typedef struct
{
short a;
int b;
short c;
int d;
}
example;
in PL/1;
DCL 1 EXAMPLE,
3 A BIN FIXED (15),
3 B BIN FIXED (31),
3 C BIN FIXED (15),
Hello Ze'ev,
unless the structure is defined with the nonstandard extension Packed
(or _Packed, I don't recall it exactly), all ints or longs will be
aligned on
a 4 byte boundary, that is, in a sequence of int, short, int, short, you
will
get two padding bytes after every short field (which is
I want to publicly thank Retired Mainframer for leading me to the correct
direction. The problem was that the EBCDIC oriented regmatch_t structure is
defined like this:
typedef struct { /* substring locations - from regexec() */
__off_t rm_so; /* offset of
While I agree on that on a philosophical point of view,
what are the real technical implication of that C design decision?
Every 20 years, when there is a major architecture extension
(for example 32 bit to 64 bit), some work has to be done, when
for example long changes the meaning from 32-bit
On Thu, 19 Feb 2015 08:18:05 -0600, Ze'ev Atlas zatl...@yahoo.com wrote:
I still think that the decision, many decades ago, to leave the actual
definition and implementation of short, int, long, etc. to the implementation
rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted.
Sure I could, but the geniuses who created the regex.h and friends did not deem
that necessary, so the poor user has to go to the header file, read all the
#if's and #else's and figure it our. Not an easy task when you are a COBOL
poor user :(
ZA
I am going back to the drawing board and I will have a hard look at the regex.h
again and will do some tests with 64 bits compilations vs. 32 bits.
It is extremely hard to deduce from the documentation what to expect and what
structure is in effect when one compiles with any combination of
In 1346088131080403.wa.zatlas1yahoo@listserv.ua.edu, on
02/19/2015
at 08:18 AM, Ze'ev Atlas
004b34e7c98a-dmarc-requ...@listserv.ua.edu said:
I still think that the decision, many decades ago, to leave the
actual definition and implementation of short, int, long, etc. to
the
One of the machines is rather old and one is much more current (1.6 vs 1.10 I
believe but will check again tonight - I am only a user)
I did it with COBOL 4.2 and 5.1 with same results. I do not remember the C
compiler levels but the behavior was consistent, and WRONG in all combinations.
I
Hello Ze'ev,
I post your source once again, because it was split into different lines
and not
very readable.
#include regex.h
#include locale.h
#include stdio.h
#include stdlib.h
extern void DUMPMEM(char *address, int length);
#include zatoolib.h
main()
{
regex_t preg;
char *string = a
bit mode, a long is only 4 bytes
while in 64 bit mode it is 8.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ze'ev Atlas
Sent: Wednesday, February 18, 2015 6:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A possible bug in the IBM
I am sorry for the typo, I was expecting (0,15),(2,8) and not (0,15),(8,2)
long 0
long 15
long 2
long 8
I ran it in z/OS which should default to normal numbers so all classic LE
languages would understand it correctly
19819478 | 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 |
Thank you for reposting
The use of my_size was indeed wrong, so I dumped more than I needed. Only
first two lines are relevant! I did not want to compile and run again because
it was late at night
I do not have access now, but the definition of regmatch_t is in the regex.h.
Regardless of
Ze'ev Atlas wrote:
I suspect (and can prove that there is a bug in the regexec function. I have
encountered this issue on two z/OS systems with two different z/OS level. The
proof is repeatable and produce same wrong results any time.
What levels of C libraries and z/OS are you using? Is
Hi all
I suspect (and can prove that there is a bug in the regexec function. I have
encountered this issue on two z/OS systems with two different z/OS level. The
proof is repeatable and produce same wrong results any time.
To prove it I modified a sample C program from the IBM manual and
22 matches
Mail list logo
