I think the descriptors changed the first time when going from OS PL/I
V1.5 to 2.0.
However, this is a *stand-alone self-contained* program, so CMPAT
mixing cannot be the cause of the problem.
On Mon, Apr 2, 2012 at 14:23, Bernd Oppolzer <email@example.com> wrote:
> Unfortunately, P.E. seems to be on vacation in Europe,
> so we will not get an answer from him soon.
> I guess that the difference between V3 and V2 is in the layout of
> the descriptors, for example. We had similar differences between
> the descriptor layout of some older compilers (don't recall the version),
> where, for example, the array limits (or aggregate component offsets)
> were BIN FIXED(15) etc. and they are now - with CMPAT(V2) - BIN FIXED(31).
> But the string lengths in
> the CHAR descriptors are still BIN FIXED(15). I guess that with V3 there
> will again be incompatible changes to the layout of CHAR, structure
> and table descriptors, so that it is impossible to mix modules compiled
> with different CMPAT options.
> Am 02.04.2012 12:43, schrieb A.K.:
> The Programming Guide says that 64-bit control blocks are used for V3: i.e.
> - V1: 15 bit
> - V2. 31 bit
> - V3: 63 bit
> With V3 builtin functions return BIN FIXED(63) instead of BIN FIXED(31),
> I guess this indicates that PL/I "one day" will support data in the 64-bit
> The Programming Guide says that you cannot mix V3 generated code with other
> code. Hence we have to be prepared for a migration …
> I guess you are the first customer using CMPAT(V3).
> - A.K.
> From: PL1 (language) discussions [mailto:PL1-L@LISTSERV.DARTMOUTH.EDU] On
> Behalf Of R.P.
> Sent: Monday, April 02, 2012 12:15 PM
> To: PL1-L@LISTSERV.DARTMOUTH.EDU
> Subject: Re: Enterprise PL/I V3R7 -> V3R9: S0C1 - problem with CMPAT(V3)?
> It's not ARCH that is the culprit, or at least not by itself!
> I think it's CMPAT(V3). I've recompiled with ARCH(8),CMPAT(V2) and the
> programs runs OK again.
> Due to the "wonderful" negative offset in the error message, I haven't (as
> yet) been able to figure out where things go wrong. I know the procedure,
> and given that the compiler spits out two new
> "IBM2814I I 3629 Aggregate mapping for storage allocation will be
> done by library call."
> where the aggregate and allocation code looks like:
> dcl 1 d_arr(*) ctl,
> 2 dtime fixed bin (31),
> 2 atime fixed bin (31),
> 2 wtime fixed bin (31),
> 2 itime fixed bin (31),
> 2 stime fixed bin (31),
> 2 ztime fixed bin (31),
> 2 ntime fixed bin (31),
> 2 bmstime fixed bin (31),
> 2 amstime fixed bin (31),
> 2 mdtime fixed bin (31),
> 2 matime fixed bin (31),
> 2 * char (20); /* 64 byte per element, shift... */
> alloc d_arr(trip_list.#d);
> I have, rightly or wrongly, an as yet unsubstantiated gut feeling that there
> is something happening in that area, given that this message is new for V3R9
> (as compared to V3R7)
> And while writing this reply, I changed the code to:
> put skip list('Ping 1');
> put skip list('Ping 2');
> put skip list('Ping 3');
> alloc d_arr(trip_list.#d);
> put skip list('Pong 1');
> put skip list('Pong 2');
> put skip list('Pong 3');
> and what's on SYSPRINT before the S0C1 abend?
> Yes, just:
> Ping 1
> Ping 2
> Ping 3
> The CMPAT(V2).ARCH(8) version ping-pong's without any problems. Looking at
> the listing, the main difference seems to be that CMPAT(V3) uses the
> IBMQWEMA library module, whereas CMPAT(V2) uses IBMQWDMA. There is no
> Google'able info on either of these two modules and they are not in the list