Oppolzer - Informatik / Blog

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.

R.

On Mon, Apr 2, 2012 at 14:23, Bernd Oppolzer <bernd.oppolzer@t-online.de> 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),
> etc..
>
> I guess this indicates that PL/I "one day" will support data in the 64-bit
> realm.
>
> 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
> @
http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/assist/modr9nic.html
>
> R.
>
>
>



--
R.