Migrating from OS/VS PL/I to VA PL/I 
Author Message
 Migrating from OS/VS PL/I to VA PL/I

Here's the PL/I:
 TESTPLI: PROC (PARM)
   OPTIONS(MAIN)
   REORDER;

 DCL (ALLOCATION,SUBSTR,NULL,ADDR,PLIRETV)   BUILTIN;
 DCL SYSPRINT          FILE PRINT;
 DCL X                 FIXED BIN(31);
 DCL Y                 FIXED BIN(31);
 DCL Z                 FIXED BIN(31);
 DCL TESTC            EXTERNAL ENTRY RETURNS(FIXED BIN(31));

 X = 5;
 PUT SKIP EDIT('BEFORE CALL  OF TESTC',X)(A,X(2),P'99');
 Z = TESTC(X);
 PUT SKIP EDIT('AFTER  CALL  OF TESTC',Z)(A,X(2),P'9999');

 END TESTPLI;

and here's the C program:

// THIS IS C, NOT C++

#pragma csect(CODE,"TESTCC")            /* code section name    */
#pragma csect(STATIC,"TESTCS")          /* static section name  */
#pragma csect(TEST,"TESTCT")            /* debug section name   */

#pragma linkage(TESTC,PLI)
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int TESTC (int *c_int)
{
  int ret = 678;
  fprintf(stdout,"TESTC: Passed in: %d, \n",*c_int);
  *c_int += 5;
  (*c_int)++;
  fprintf(stdout,"TESTC: Changed it to: %d, \n",*c_int);

 return(ret);

Quote:
}

The C compiler is "5647A01 V2 R4 M00 OS/390 C"

When I compile TESTPLI with PL/I for MVS/VM output is:
 BROWSE - SYSPRINT          STEPZ    -   Record
 COMMAND ===>,
******************************** Top of Data *****
BEFORE FETCH OF TESTC
TESTC: Passed in: 39,
TESTC: Changed it to: 45,
BEFORE CALL  OF TESTC  05
AFTER  CALL  OF TESTC  0678
 ******************************* Bottom of Data **

When I compile TESTPLI with VA PL/I outputs are:
 BROWSE - SYSPRINT          STEPZ    -   Record
 COMMAND ===>,
******************************** Top of Data ******
BEFORE FETCH OF TESTC
BEFORE CALL  OF TESTC  05
AFTER  CALL  OF TESTC  0678
 ******************************* Bottom of Data ***
and
 BROWSE - SYS00001          STEPZ    -   Record
 COMMAND ===>,
******************************** Top of Data ******
TESTC: Passed in: 5,
TESTC: Changed it to: 11,
 ******************************* Bottom of Data ***


Quote:
> On Wed, 28 Nov 2001 13:21:32 -0500, in article

> >4. PL/I calling C.  A PL/I "Hello World" program puts out a message (PUT
> >EDIT defaulting to SYSPRINT), then calls a C subroutine which puts out a
> >message (fprintf(stdout...)) and returns to the PL/I main which puts out
> >another message.  When the PL/I program is compiled with PLI for MVS/VM,
the
> >messages go to SYSPRINT,  "Hello from PL/I,"  "Hello from C," "Hello
again
> >from PL/I"  When the PL/I program is compiled with VA PL/I, the C
> >subroutine's messages go to a new (system generated) file named SYS00001,
so
> >the order in which they were issued is no longer visable.  There were no
> >code changes to either the C subroutine or the PL/I main - re-compiling
the
> >PL/I code made the C code act differently.

> What version of the C-Compiler do you use? How do you call the C-Module
(fetch,
> linked, DLL?). I have a "Hello World" sample that works. In more complex
> situation, I have some problems: Sometimes, the order on SYSPRINT is not
> correct, sometimes, the last line is suppressed, but I never had an extra
file.



Tue, 18 May 2004 02:25:52 GMT  
 Migrating from OS/VS PL/I to VA PL/I
That works!  Thanks.


Quote:
> On Wed, 28 Nov 2001 13:21:32 -0500, in article

> >5. Whenever I re-compile an OEDRIV subroutine with VA PL/I as opposed to
PLI
> >for MVS/VM, the CSECT name stops showing up in the OEDRIV load module
when I
> >look at it using FileAid.  Since OEDRIV has over a hundred source/obj
> >members linked into one load module, we often need to look at the load
> >module to see where everything came from.

> Use the compile parameter CSECT and you'll find your names! This option
was
> introduced with a PTF, maybe you have to upgrade your compiler to a more
current
> version.



Tue, 18 May 2004 03:48:13 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Quote:

> I agree.  I've MADE the same statment several times.  Until now it was never
> true. :-) But this one is pretty straightforward.
> TAG is CHAR(3).  The message points to the SELECT line.

> SELECT (TAG);
>    WHEN ('FNB', 'TBB', 'IUB', 'IVB', 'CSP', 'PAG', 'NPG')
>       DO;
>          TOKEN_LTH  = TOKEN_LEN;
>          AFTER_PAGE = YES;
>       END;
>    WHEN ('HLB', 'PAR', 'KWE', 'ITB', 'USB', 'BDB',
>          'SIB', 'SDB')
>       DO;
>          TOKEN_LTH  = TOKEN_LEN;
>          NBR_BEFORE = YES;
>       END;

>    WHEN ('KWB', 'HLE', 'FNE', 'ITE', 'USE', 'ESG', 'RWS',
>          'TBE', 'IUE', 'BDE', 'SIE', 'IVE', 'NDI',
>          'SGM', 'NCK', 'NLR', 'NLL', 'NLC', 'IVE', 'PNC')

'IVE' appears twice in this WHEN

Quote:
>       DO;
>          TOKEN_LTH = TOKEN_LEN;
>          NBR_AFTER = YES;
>       END;
>    OTHERWISE AFTER_PAGE = YES;

Don't know what you're up to, but is "TOKEN_LTH=TOKEN_LEN;" needed in the otherwise?

- Show quoted text -

Quote:
> END;



> > On Wed, 28 Nov 2001 13:21:32 -0500, in article

> > >3. Got message "IBM1192I - When clauses contain duplicate values."  The
> > >explanation says it means the duplicate occurrence of the WHEN clause
> will
> > >never get executed.  This would have been a good message if it were true,
> > >however they don't have duplicate values!

> > I heard that  same statement several times. Until now, it was never true.
> > Sometimes I have to work half an hour to find out that the Compiler
> generated
> > message is true. Please post your whole SELECT!  I am pretty sure that I
> will be
> > able to detect the reason of this message.



Tue, 18 May 2004 12:38:59 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Please post the JCL / CLIST / REXX. Your LE options may also be helpful.

Quote:

> Here's the PL/I:
>  TESTPLI: PROC (PARM)
>    OPTIONS(MAIN)
>    REORDER;

>  DCL (ALLOCATION,SUBSTR,NULL,ADDR,PLIRETV)   BUILTIN;
>  DCL SYSPRINT          FILE PRINT;
>  DCL X                 FIXED BIN(31);
>  DCL Y                 FIXED BIN(31);
>  DCL Z                 FIXED BIN(31);
>  DCL TESTC            EXTERNAL ENTRY RETURNS(FIXED BIN(31));

>  X = 5;
>  PUT SKIP EDIT('BEFORE CALL  OF TESTC',X)(A,X(2),P'99');
>  Z = TESTC(X);
>  PUT SKIP EDIT('AFTER  CALL  OF TESTC',Z)(A,X(2),P'9999');

>  END TESTPLI;

> and here's the C program:

> // THIS IS C, NOT C++

> #pragma csect(CODE,"TESTCC")            /* code section name    */
> #pragma csect(STATIC,"TESTCS")          /* static section name  */
> #pragma csect(TEST,"TESTCT")            /* debug section name   */

> #pragma linkage(TESTC,PLI)
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> int TESTC (int *c_int)
> {
>   int ret = 678;
>   fprintf(stdout,"TESTC: Passed in: %d, \n",*c_int);
>   *c_int += 5;
>   (*c_int)++;
>   fprintf(stdout,"TESTC: Changed it to: %d, \n",*c_int);

>  return(ret);

> }

> The C compiler is "5647A01 V2 R4 M00 OS/390 C"

> When I compile TESTPLI with PL/I for MVS/VM output is:
>  BROWSE - SYSPRINT          STEPZ    -   Record
>  COMMAND ===>,
> ******************************** Top of Data *****
> BEFORE FETCH OF TESTC
> TESTC: Passed in: 39,
> TESTC: Changed it to: 45,
> BEFORE CALL  OF TESTC  05
> AFTER  CALL  OF TESTC  0678
>  ******************************* Bottom of Data **

> When I compile TESTPLI with VA PL/I outputs are:
>  BROWSE - SYSPRINT          STEPZ    -   Record
>  COMMAND ===>,
> ******************************** Top of Data ******
> BEFORE FETCH OF TESTC
> BEFORE CALL  OF TESTC  05
> AFTER  CALL  OF TESTC  0678
>  ******************************* Bottom of Data ***
> and
>  BROWSE - SYS00001          STEPZ    -   Record
>  COMMAND ===>,
> ******************************** Top of Data ******
> TESTC: Passed in: 5,
> TESTC: Changed it to: 11,
>  ******************************* Bottom of Data ***



> > On Wed, 28 Nov 2001 13:21:32 -0500, in article

> > >4. PL/I calling C.  A PL/I "Hello World" program puts out a message
(PUT
> > >EDIT defaulting to SYSPRINT), then calls a C subroutine which puts out
a
> > >message (fprintf(stdout...)) and returns to the PL/I main which puts
out
> > >another message.  When the PL/I program is compiled with PLI for
MVS/VM,
> the
> > >messages go to SYSPRINT,  "Hello from PL/I,"  "Hello from C," "Hello
> again
> > >from PL/I"  When the PL/I program is compiled with VA PL/I, the C
> > >subroutine's messages go to a new (system generated) file named
SYS00001,
> so
> > >the order in which they were issued is no longer visable.  There were
no
> > >code changes to either the C subroutine or the PL/I main - re-compiling
> the
> > >PL/I code made the C code act differently.

> > What version of the C-Compiler do you use? How do you call the C-Module
> (fetch,
> > linked, DLL?). I have a "Hello World" sample that works. In more complex
> > situation, I have some problems: Sometimes, the order on SYSPRINT is not
> > correct, sometimes, the last line is suppressed, but I never had an
extra
> file.



Tue, 18 May 2004 17:56:04 GMT  
 Migrating from OS/VS PL/I to VA PL/I
On Thu, 29 Nov 2001 13:21:10 -0500, in article

Quote:

>Thanks for your response Daniel.  I'll reply one at a time to make them
>smaller, and because they won't be in order.

Seems a good idea. Let's do so.

Quote:

>I'm not talking about the message here, rather about the line numbering.  In
>PL/I for MVS and VM, the listing has a number for each EXECUTABLE statement;
>but in VA PL/I the number is for each line in the source member.  There are
>advantages to BOTH methods; it depends on what you're doing at the time. I'm
>just pointing out the disadvantage of this method when there's a macro that
>expands to a large number of statements.

Sorry, I do not have this problem. My compile listing shows every single line of
every macro. Do you have some  %noprint statements in some of your macros?

-------------------------------------------------
With kind regards
Daniel Jacot
-------------------------------------------------
visit us at: http://www.winterthur.com



Tue, 18 May 2004 18:27:22 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Peter,

I fully agree that the compiler should not point to the SELECT statement, but
rather to the last WHEN where 'IVE' is duplicate. I even agree that it is not a
problem in this particular case..
But, if you would have had mentioned one or more of your values in two or more
WHEN clauses, which one in which form should be flaged by the compiler?

On Thu, 29 Nov 2001 13:22:47 -0500, in article

Quote:

>I agree.  I've MADE the same statment several times.  Until now it was never
>true. :-) But this one is pretty straightforward.
>TAG is CHAR(3).  The message points to the SELECT line.

>SELECT (TAG);
>   WHEN ('FNB', 'TBB', 'IUB', 'IVB', 'CSP', 'PAG', 'NPG')
>      DO;
>         TOKEN_LTH  = TOKEN_LEN;
>         AFTER_PAGE = YES;
>      END;
>   WHEN ('HLB', 'PAR', 'KWE', 'ITB', 'USB', 'BDB',
>         'SIB', 'SDB')
>      DO;
>         TOKEN_LTH  = TOKEN_LEN;
>         NBR_BEFORE = YES;
>      END;

>   WHEN ('KWB', 'HLE', 'FNE', 'ITE', 'USE', 'ESG', 'RWS',
>         'TBE', 'IUE', 'BDE', 'SIE', 'IVE', 'NDI',
>         'SGM', 'NCK', 'NLR', 'NLL', 'NLC', 'IVE', 'PNC')
>      DO;
>         TOKEN_LTH = TOKEN_LEN;
>         NBR_AFTER = YES;
>      END;
>   OTHERWISE AFTER_PAGE = YES;
>END;

-------------------------------------------------
With kind regards
Daniel Jacot
-------------------------------------------------
visit us at: http://www.winterthur.com


Tue, 18 May 2004 18:38:34 GMT  
 Migrating from OS/VS PL/I to VA PL/I
From what I've posted, you could get that impression.  However, just before
the SELECT, is the comment:
/* NOTE TOKEN_LTH IS NOT */

/* INCRMENTED IN ALL CASES */

/* (OTHERWISE CLAUSE). */

Most of the code I'm talking about in this thread (all but the HELLO WORLD)
is currently running in production.  I'm trying not to re-engineer any more
than I have to.  All I want is to get it compiled and running in VA PL/I.

Greg



Quote:

> > I agree.  I've MADE the same statment several times.  Until now it was
never
> > true. :-) But this one is pretty straightforward.
> > TAG is CHAR(3).  The message points to the SELECT line.

> > SELECT (TAG);
> >    WHEN ('FNB', 'TBB', 'IUB', 'IVB', 'CSP', 'PAG', 'NPG')
> >       DO;
> >          TOKEN_LTH  = TOKEN_LEN;
> >          AFTER_PAGE = YES;
> >       END;
> >    WHEN ('HLB', 'PAR', 'KWE', 'ITB', 'USB', 'BDB',
> >          'SIB', 'SDB')
> >       DO;
> >          TOKEN_LTH  = TOKEN_LEN;
> >          NBR_BEFORE = YES;
> >       END;

> >    WHEN ('KWB', 'HLE', 'FNE', 'ITE', 'USE', 'ESG', 'RWS',
> >          'TBE', 'IUE', 'BDE', 'SIE', 'IVE', 'NDI',
> >          'SGM', 'NCK', 'NLR', 'NLL', 'NLC', 'IVE', 'PNC')

> 'IVE' appears twice in this WHEN

> >       DO;
> >          TOKEN_LTH = TOKEN_LEN;
> >          NBR_AFTER = YES;
> >       END;
> >    OTHERWISE AFTER_PAGE = YES;

> Don't know what you're up to, but is "TOKEN_LTH=TOKEN_LEN;" needed in the
otherwise?

> > END;



> > > On Wed, 28 Nov 2001 13:21:32 -0500, in article

> > > >3. Got message "IBM1192I - When clauses contain duplicate values."
The
> > > >explanation says it means the duplicate occurrence of the WHEN clause
> > will
> > > >never get executed.  This would have been a good message if it were
true,
> > > >however they don't have duplicate values!

> > > I heard that  same statement several times. Until now, it was never
true.
> > > Sometimes I have to work half an hour to find out that the Compiler
> > generated
> > > message is true. Please post your whole SELECT!  I am pretty sure that
I
> > will be
> > > able to detect the reason of this message.



Tue, 18 May 2004 21:28:42 GMT  
 Migrating from OS/VS PL/I to VA PL/I
You're right.  I didn't look for duplicates within the same WHEN.  The
message is perfectly reasonable for that condition.  I removed the second
IVE from the last WHEN and the message went away.  I owe you a Guiness.
(Keep watching your e-mail)

Greg


Quote:
> Peter,

> I fully agree that the compiler should not point to the SELECT statement,
but
> rather to the last WHEN where 'IVE' is duplicate. I even agree that it is
not a
> problem in this particular case..
> But, if you would have had mentioned one or more of your values in two or
more
> WHEN clauses, which one in which form should be flaged by the compiler?

> On Thu, 29 Nov 2001 13:22:47 -0500, in article

> >I agree.  I've MADE the same statment several times.  Until now it was
never
> >true. :-) But this one is pretty straightforward.
> >TAG is CHAR(3).  The message points to the SELECT line.

> >SELECT (TAG);
> >   WHEN ('FNB', 'TBB', 'IUB', 'IVB', 'CSP', 'PAG', 'NPG')
> >      DO;
> >         TOKEN_LTH  = TOKEN_LEN;
> >         AFTER_PAGE = YES;
> >      END;
> >   WHEN ('HLB', 'PAR', 'KWE', 'ITB', 'USB', 'BDB',
> >         'SIB', 'SDB')
> >      DO;
> >         TOKEN_LTH  = TOKEN_LEN;
> >         NBR_BEFORE = YES;
> >      END;

> >   WHEN ('KWB', 'HLE', 'FNE', 'ITE', 'USE', 'ESG', 'RWS',
> >         'TBE', 'IUE', 'BDE', 'SIE', 'IVE', 'NDI',
> >         'SGM', 'NCK', 'NLR', 'NLL', 'NLC', 'IVE', 'PNC')
> >      DO;
> >         TOKEN_LTH = TOKEN_LEN;
> >         NBR_AFTER = YES;
> >      END;
> >   OTHERWISE AFTER_PAGE = YES;
> >END;

> -------------------------------------------------
> With kind regards
> Daniel Jacot
> -------------------------------------------------
> visit us at: http://www.winterthur.com



Tue, 18 May 2004 21:37:50 GMT  
 Migrating from OS/VS PL/I to VA PL/I
OK, I was wrong, I get the about the same result as you do, except that the C
output is on a file SYS0002 instead of your SYS0001. Strange anyway. I have a
more current version of the C compiler (V2R10).

I'll mail you a Haldengut as soon as I get your Guiness!

Cheers!

Daniel

On Thu, 29 Nov 2001 13:25:52 -0500, in article

Quote:

>Here's the PL/I:
> TESTPLI: PROC (PARM)
>   OPTIONS(MAIN)
>   REORDER;

> DCL (ALLOCATION,SUBSTR,NULL,ADDR,PLIRETV)   BUILTIN;
> DCL SYSPRINT          FILE PRINT;
> DCL X                 FIXED BIN(31);
> DCL Y                 FIXED BIN(31);
> DCL Z                 FIXED BIN(31);
> DCL TESTC            EXTERNAL ENTRY RETURNS(FIXED BIN(31));

> X = 5;
> PUT SKIP EDIT('BEFORE CALL  OF TESTC',X)(A,X(2),P'99');
> Z = TESTC(X);
> PUT SKIP EDIT('AFTER  CALL  OF TESTC',Z)(A,X(2),P'9999');

> END TESTPLI;

>and here's the C program:

>// THIS IS C, NOT C++

>#pragma csect(CODE,"TESTCC")            /* code section name    */
>#pragma csect(STATIC,"TESTCS")          /* static section name  */
>#pragma csect(TEST,"TESTCT")            /* debug section name   */

>#pragma linkage(TESTC,PLI)
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>int TESTC (int *c_int)
>{
>  int ret = 678;
>  fprintf(stdout,"TESTC: Passed in: %d, \n",*c_int);
>  *c_int += 5;
>  (*c_int)++;
>  fprintf(stdout,"TESTC: Changed it to: %d, \n",*c_int);

> return(ret);

>}

>The C compiler is "5647A01 V2 R4 M00 OS/390 C"

>When I compile TESTPLI with PL/I for MVS/VM output is:
> BROWSE - SYSPRINT          STEPZ    -   Record
> COMMAND ===>,
>******************************** Top of Data *****
>BEFORE FETCH OF TESTC
>TESTC: Passed in: 39,
>TESTC: Changed it to: 45,
>BEFORE CALL  OF TESTC  05
>AFTER  CALL  OF TESTC  0678
> ******************************* Bottom of Data **

>When I compile TESTPLI with VA PL/I outputs are:
> BROWSE - SYSPRINT          STEPZ    -   Record
> COMMAND ===>,
>******************************** Top of Data ******
>BEFORE FETCH OF TESTC
>BEFORE CALL  OF TESTC  05
>AFTER  CALL  OF TESTC  0678
> ******************************* Bottom of Data ***
>and
> BROWSE - SYS00001          STEPZ    -   Record
> COMMAND ===>,
>******************************** Top of Data ******
>TESTC: Passed in: 5,
>TESTC: Changed it to: 11,
> ******************************* Bottom of Data ***

-------------------------------------------------
With kind regards
Daniel Jacot
-------------------------------------------------
visit us at: http://www.winterthur.com


Tue, 18 May 2004 23:01:56 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Before we get too deeply into it, I have found a partial solution to of this
problem, but I still don't like it.
Here's the original problem:  I compiled and got these two messages:

IBM1099I W   762.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.
IBM1099I W   762.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.

I know it's a warning message, but the bit about "significant digits may be
lost" frightened me, so I decided to investigate.  First, I tried to find a
FIXED DEC(15,0) operand. The source has nothing declared DEC. The xref
listing shows nothing declared as DEC. (I have 'A(FULL)' and 'X(FULL)' in
the OPTIONS list.)  Next, I looked in the message manual and the wording was
different from what I have in my listing - it talked about DO groups.  So I
looked at the code.

Here's the source around line 762. (CTLCRD is a PL/I macro):
000762,0  CTLCRD NAME (SEG)
000763,          MULTIPLE (255) BOOLEAN;
000764,0/********************************************************/
000765, /*            Begin Mod for Emb. Statute Cites          */
000766, /********************************************************/
000767,0  CTLCRD NAME (STRIPBTN4)

 Here's the listing, showing the macro expanded (page breaks removed). Note
the abundance of lines numbered "762.1":

762.1,    2  4 0         END;
762.1                    /*
762.1                      CTLCRD
762.1                        NAME (SEG)
762.1                        MULTIPLE (255)
762.1                        BOOLEAN
762.1                    */
762.1     2  3           WHEN ('SEG') DO;
762.1     2  4             CTLSEP = ' ';
762.1     2  4             CTLVAL = CTLVAL || ' ';
762.1     2  4             DO UNTIL (CTLSEP = ' ');
762.1     2  5               I = VERIFY(CTLVAL, '0123456789') - 1;
762.1     2  5               IF I < 1 | I > 15 THEN DO;
762.1     2  6                 CTLSEP = ' ';
762.1     2  6                 CTLECT = CTLECT + 1;
762.1     2  6                 PUT FILE (MSGPRT) EDIT
762.1                            ('Value must be <= 15 numeric digits')
762.1                            (SKIP, A);
762.1     2  6               END;
762.1     2  5               ELSE DO;
762.1     2  6                 CTLPIC = 0;
762.1     2  6                 SUBSTR(CTLCHR,16-I,I) = SUBSTR(CTLVAL,1,I);
762.1     2  6                 IF CTLPIC < LBOUND(SEG,1) |              <===
note this line
762.1     2  6                    CTLPIC > HBOUND(SEG,1) THEN DO;       <===
note this line
762.1     2  7                   CTLSEP = ' ';
762.1     2  7                   CTLECT = CTLECT + 1;
762.1     2  7                   PUT FILE (MSGPRT) EDIT
762.1                              ('Value is not within valid range')
762.1                              (SKIP, A);
762.1     2  7                 END;
762.1     2  6                 ELSE DO;
762.1     2  7                   K = CTLPIC;
762.1     2  7                   IF CTLSEP = '-' THEN
762.1     2  7                     DO J = J + 1 TO K;
762.1     2  8                       SEG_CNT =
762.1                                SEG_CNT + 1;
762.1     2  8                       SEG(J) = '1'B;
762.1     2  8                     END;
762.1     2  7                   ELSE
762.1     2  7                     DO J = K;
762.1     2  8                       SEG_CNT =
762.1                                SEG_CNT + 1;
762.1     2  8                       SEG(J) = '1'B;
762.1     2  8                     END;
762.1     2  7                   CTLSEP = SUBSTR(CTLVAL,I+1,1);
762.1     2  7                   IF CTLSEP ?= ',' & CTLSEP ?= '-' & CTLSEP
?= ' ' THEN D
762.1     2  7   O;                CTLSEP = ' ';
762.1     2  8                     CTLECT = CTLECT + 1;
762.1     2  8                     PUT FILE (MSGPRT) EDIT
762.1                                ('Invalid character')
762.1                                (SKIP, A);
762.1     2  8                   END;
762.1     2  7                   ELSE
762.1     2  7                     CTLVAL = SUBSTR(CTLVAL,I+2);
762.1     2  7                 END;
762.1     2  6               END;
762.1     2  5             END;
764.1          0 /********************************************************/
765.1            /*            Begin Mod for Emb. Statute Cites          */
766.1            /********************************************************/
767.1     2  4 0         END;

The partial solution was to run the source through the compiler twice: first
with OPTIONS=MACRO, NOCOMPILE, MDECK, NOSYNTAX to produce a source deck with
the macro expanded; then a second run to compile that source deck.  Now the
lines are all uniquely numbered.  That seems like a lot just to get proper
line numbers. Plus, the messages are still confusing.  The messages both now
point to line 1524.1:
IBM1099I W  1524.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.
IBM1099I W  1524.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.

Lines 1524.2 and 1525.1 turn out to be:
1524.1,    2  6                 IF CTLPIC < LBOUND(SEG,1) |
1525.1     2  6                    CTLPIC > HBOUND(SEG,1) THEN DO;

CTLPIC is declared  PIC '(15)9-' STATIC INIT (0);
LBOUND and HBOUND return a FIXED BINARY (M,0) value.
SEG is FIXED BIN(15).

Greg


Quote:
> On Thu, 29 Nov 2001 13:21:10 -0500, in article

> >Thanks for your response Daniel.  I'll reply one at a time to make them
> >smaller, and because they won't be in order.

> Seems a good idea. Let's do so.

> >I'm not talking about the message here, rather about the line numbering.
In
> >PL/I for MVS and VM, the listing has a number for each EXECUTABLE
statement;
> >but in VA PL/I the number is for each line in the source member.  There
are
> >advantages to BOTH methods; it depends on what you're doing at the time.
I'm
> >just pointing out the disadvantage of this method when there's a macro
that
> >expands to a large number of statements.

> Sorry, I do not have this problem. My compile listing shows every single
line of
> every macro. Do you have some  %noprint statements in some of your macros?

> -------------------------------------------------
> With kind regards
> Daniel Jacot
> -------------------------------------------------
> visit us at: http://www.winterthur.com



Wed, 19 May 2004 02:30:24 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Date: Wed, 28 Nov 2001 13:21:32 -0500
.
I didn't want to include a littany of my problems with my first post,
because it sounded kind of whiney, but you asked for it so here's a
selection of the problems I have hit so far:
.
1. Got message "IBM1099I - FIXED DEC(11,0) operand will be converted to
FIXED BIN(31,0). Significant digits may be lost." It didn't tell me which
variable (there were three on the line, none of which was DEC(11,0)).  I
loaded the message manual down from the IBM site, and their explanation of
the message was completely different: "IBM1099I W Code generated for DO
group would be more efficient if control variable were a 4-byte integer.
Explanation: The control variable in the DO loop is a 1-byte or 2-byte
integer, and consequently, the code generated for the loop will not be
optimal." It is pointing to one line in a DO/END group, and it's not even a
controlled DO/END.
.
==================
see previous post.
==================
.
2. Compiled a module with a local macro that is used extensively.  I haven't
run it, but it looks like it went through the compiler OK.  However, the
line numbering stinks. When compiling, I got a bogus message (See #1 above)
on a line that was a call to the macro.  All lines in the call and in the
macro had the same source code line identifier, and that was the line number
in the message.  In other words, there was a message pointing to LINE 373.1,
but there were 58 lines numbered 373.1.  Didn't narrow it down much.
.
==================
see previous post.
==================
.
3. Got message "IBM1192I - When clauses contain duplicate values."  The
explanation says it means the duplicate occurrence of the WHEN clause will
never get executed.  This would have been a good message if it were true,
however they don't have duplicate values!
.
===================
Might need to carefully check those WHEN values.
===================
.
4. PL/I calling C.  A PL/I "Hello World" program puts out a message (PUT
EDIT defaulting to SYSPRINT), then calls a C subroutine which puts out a
message (fprintf(stdout...)) and returns to the PL/I main which puts out
another message.  When the PL/I program is compiled with PLI for MVS/VM, the
messages go to SYSPRINT,  "Hello from PL/I,"  "Hello from C," "Hello again
from PL/I"  When the PL/I program is compiled with VA PL/I, the C
subroutine's messages go to a new (system generated) file named SYS00001, so
the order in which they were issued is no longer visable.  There were no
code changes to either the C subroutine or the PL/I main - re-compiling the
PL/I code made the C code act differently.
.
5. Whenever I re-compile an OEDRIV subroutine with VA PL/I as opposed to PLI
for MVS/VM, the CSECT name stops showing up in the OEDRIV load module when I
look at it using FileAid.  Since OEDRIV has over a hundred source/obj
members linked into one load module, we often need to look at the load
module to see where everything came from.
.
==============
Might need to take that up with Peter Elderon.
==============
.
6.  Getting messages:
IBM1617I S   136.1     DIRECT attribute for file EXPL needs ENVIRONMENT
option specification of INDEXED, REGIONAL, RELATIVE, or VSAM.
IBM1243I E   136.1     REGIONAL(3) ENVIRONMENT option is not supported.
This one is probably my own ignorance, but I don't know what REGIONAL
parameter I need.
.
7.  We use PLIDYN a lot.  With VA PL/I I get the following:
IBM1953I S  1576.1     The attributes of the EXTERNAL variable SSCDSDA do
not match those in its previous declaration.
.
==============
Did you try the OPTIONAL attribute?
==============
.
IBM2112I S  1576.1     Parameter counts do not match.
This is because PLIDYN uses the same macro name for OPEN, CLOSE, etc. but
passes different numbers of parms for each type of call.
.
8.  So I changed from PLIDYN to BPXWDYN.  BPXWDYN doesn't have a provision
for data set disposition in the case of abnormal termination  (i.e.: Can't
say NEW,DELETE,DELETE).  This means whenever my job fails I have to find the
data set (it's not cataloged) and delete it myself.
9.  When linking I keep getting Sys 0F4 abend.  This has been cured by
coding LIMITS(EXTNAME(8)) but I have heard this negates a lot of the "good
stuff" that VA PL/I should be providing.
.
==============
I can't imagine why the good stuff would be negated.  Might be a rumor.
==============
.
10.  I don't get the nice LE dumps that tell me exactly which line is in
error.  The dumps that look like they worked give an offset into the load
module.  The load module is pretty big, and it's difficult to figure out
which subroutine is in error.
.
==============
Is the STMT option available?
==============
.
11.  That's when the dumps work.  I get a lot of dumps that say, "PLIDUMP
was called from offset +xxxxxxx from _ON_Begin_289_Blk_2 with entry address
yyyyyyy."  I have no idea where  _ON_Begin_289_Blk_2 comes from.
.
==============
Is the STMT option available?
==============
.
12. I have been adding PUT EDIT statements (like "I GOT TO HERE.") to help
with troubleshooting.  One module started failing after one of these PUT
EDIT statements which was just before a subroutine.  I removed the PUT EDIT
which came AFTER the subroutine, and it stopped failing and ran the
subroutine.  Later, in a different part of the same module, I had occasion
to add and remove more of these PUT EDIT statements, and it started failing
right before the aformentioned subroutine again. It looked like there was
some critical mass of PUT EDIT which could not be exceeded.  I haven't got
this module working yet, so I have no answer to this one.
.
============
Try enabling SUBSCRIPTRANGE, STRINGRANGE, SIZE.
============
.
And it goes on...
Greg
============
HTH.


Wed, 19 May 2004 08:12:45 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Quote:

> I agree.  I've MADE the same statment several times.  Until now it was never
> true. :-) But this one is pretty straightforward.
> TAG is CHAR(3).  The message points to the SELECT line.

> SELECT (TAG);
>    WHEN ('FNB', 'TBB', 'IUB', 'IVB', 'CSP', 'PAG', 'NPG')
>       DO;
>          TOKEN_LTH  = TOKEN_LEN;
>          AFTER_PAGE = YES;
>       END;
>    WHEN ('HLB', 'PAR', 'KWE', 'ITB', 'USB', 'BDB',
>          'SIB', 'SDB')
>       DO;
>          TOKEN_LTH  = TOKEN_LEN;
>          NBR_BEFORE = YES;
>       END;

>    WHEN ('KWB', 'HLE', 'FNE', 'ITE', 'USE', 'ESG', 'RWS',
>          'TBE', 'IUE', 'BDE', 'SIE', 'IVE', 'NDI',

                                        ~~~
Quote:
>          'SGM', 'NCK', 'NLR', 'NLL', 'NLC', 'IVE', 'PNC')

                                               ~~~
The expression 'IVE' is duplicated in this list.

- Show quoted text -

Quote:
>       DO;
>          TOKEN_LTH = TOKEN_LEN;
>          NBR_AFTER = YES;
>       END;
>    OTHERWISE AFTER_PAGE = YES;
> END;



> > On Wed, 28 Nov 2001 13:21:32 -0500, in article

> > >3. Got message "IBM1192I - When clauses contain duplicate values."  The
> > >explanation says it means the duplicate occurrence of the WHEN clause
> will
> > >never get executed.  This would have been a good message if it were true,
> > >however they don't have duplicate values!

Yes, there is at least one duplicate.  See above.
Matybe you should check for other duplicates.

- Show quoted text -

Quote:
> > I heard that  same statement several times. Until now, it was never true.
> > Sometimes I have to work half an hour to find out that the Compiler
> generated
> > message is true. Please post your whole SELECT!  I am pretty sure that I
> will be
> > able to detect the reason of this message.



Wed, 19 May 2004 08:18:46 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Before we get too deeply into it, I have found a partial solution to of this
problem, but I still don't like it.
Here's the original problem:  I compiled and got these two messages:

IBM1099I W   762.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.
IBM1099I W   762.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.

I know it's a warning message, but the bit about "significant digits may be
lost" frightened me, so I decided to investigate.  First, I tried to find a
FIXED DEC(15,0) operand. The source has nothing declared DEC. The xref
listing shows nothing declared as DEC. (I have 'A(FULL)' and 'X(FULL)' in
the OPTIONS list.)  Next, I looked in the message manual and the wording was
different from what I have in my listing - it talked about DO groups.  So I
looked at the code.

[...]

The partial solution was to run the source through the compiler twice: first
with OPTIONS=MACRO, NOCOMPILE, MDECK, NOSYNTAX to produce a source deck with
the macro expanded; then a second run to compile that source deck.  Now the
lines are all uniquely numbered.  That seems like a lot just to get proper
line numbers. Plus, the messages are still confusing.  The messages both now
point to line 1524.1:
IBM1099I W  1524.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.
IBM1099I W  1524.1     FIXED DEC(15,0) operand will be converted to FIXED
                       BIN(31,0). Significant digits may be lost.

Lines 1524.2 and 1525.1 turn out to be:
1524.1,    2  6                 IF CTLPIC < LBOUND(SEG,1) |
1525.1     2  6                    CTLPIC > HBOUND(SEG,1) THEN DO;

==================
Then make this:

IF CTLPIC < DECIMAL(LBOUND(SEG,1)) | etc
==================

CTLPIC is declared  PIC '(15)9-' STATIC INIT (0);
LBOUND and HBOUND return a FIXED BINARY (M,0) value.
SEG is FIXED BIN(15).

Greg



Wed, 19 May 2004 08:32:20 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Date: Thu, 29 Nov 2001 11:19:06 GMT

Quote:
> What version of the C-Compiler do you use? How do you call the C-Module (fetch,
> linked, DLL?). I have a "Hello World" sample that works. In more complex
> situation, I have some problems: Sometimes, the order on SYSPRINT is not
> correct, sometimes, the last line is suppressed, but I never had an extra file.

PL/I output may come out-of-sequence if a PUT SKIP is not issued
prior to calling C (or any other language),
on account of the buffer not being cleared.
Quote:
>-------------------------------------------------
>With kind regards
>Daniel Jacot
>-------------------------------------------------



Thu, 20 May 2004 07:33:07 GMT  
 Migrating from OS/VS PL/I to VA PL/I
CLTPIC is declared as p'(15)9-', and it is being compared with a fixed bin
(31) (result of lbound / hbound, but see below).

The LRM gives the rules for conversion from "Arithmetic character PICTURE"
to FIXED BINARY as "data first converts to decimal with scale and precision
determined by the corresponding PICTURE specification..."

The LRM also explains under "Data conversion in arithmetic operations" that
"if the bases of the two operands differ, the decimal operand is converted
to binary."

The final piece in the puzzle can only be presumed, as you didn''t state it.
I presume you're using limits(fixedbin(31)). Thus the result of lbound /
hbound is a fixed bin (31), and all arithmetic is carried out using fixed
bin (31).

Running through the above, we can see that CTLPIC will be converted to a
fixed bin (31), but that it may contain up to 15 decimal digits. This can -
obviously - result in the loss of significant digits, and the compiler is
telling you this.

- Mark Yudkin


Quote:

> Before we get too deeply into it, I have found a partial solution to of
this
> problem, but I still don't like it.
> Here's the original problem:  I compiled and got these two messages:

> IBM1099I W   762.1     FIXED DEC(15,0) operand will be converted to FIXED
>                        BIN(31,0). Significant digits may be lost.
> IBM1099I W   762.1     FIXED DEC(15,0) operand will be converted to FIXED
>                        BIN(31,0). Significant digits may be lost.

> I know it's a warning message, but the bit about "significant digits may
be
> lost" frightened me, so I decided to investigate.  First, I tried to find
a
> FIXED DEC(15,0) operand. The source has nothing declared DEC. The xref
> listing shows nothing declared as DEC. (I have 'A(FULL)' and 'X(FULL)' in
> the OPTIONS list.)  Next, I looked in the message manual and the wording
was
> different from what I have in my listing - it talked about DO groups.  So
I
> looked at the code.

> Here's the source around line 762. (CTLCRD is a PL/I macro):
> 000762,0  CTLCRD NAME (SEG)
> 000763,          MULTIPLE (255) BOOLEAN;
> 000764,0/********************************************************/
> 000765, /*            Begin Mod for Emb. Statute Cites          */
> 000766, /********************************************************/
> 000767,0  CTLCRD NAME (STRIPBTN4)

>  Here's the listing, showing the macro expanded (page breaks removed).
Note
> the abundance of lines numbered "762.1":

> 762.1,    2  4 0         END;
> 762.1                    /*
> 762.1                      CTLCRD
> 762.1                        NAME (SEG)
> 762.1                        MULTIPLE (255)
> 762.1                        BOOLEAN
> 762.1                    */
> 762.1     2  3           WHEN ('SEG') DO;
> 762.1     2  4             CTLSEP = ' ';
> 762.1     2  4             CTLVAL = CTLVAL || ' ';
> 762.1     2  4             DO UNTIL (CTLSEP = ' ');
> 762.1     2  5               I = VERIFY(CTLVAL, '0123456789') - 1;
> 762.1     2  5               IF I < 1 | I > 15 THEN DO;
> 762.1     2  6                 CTLSEP = ' ';
> 762.1     2  6                 CTLECT = CTLECT + 1;
> 762.1     2  6                 PUT FILE (MSGPRT) EDIT
> 762.1                            ('Value must be <= 15 numeric digits')
> 762.1                            (SKIP, A);
> 762.1     2  6               END;
> 762.1     2  5               ELSE DO;
> 762.1     2  6                 CTLPIC = 0;
> 762.1     2  6                 SUBSTR(CTLCHR,16-I,I) = SUBSTR(CTLVAL,1,I);
> 762.1     2  6                 IF CTLPIC < LBOUND(SEG,1) |
<===
> note this line
> 762.1     2  6                    CTLPIC > HBOUND(SEG,1) THEN DO;
<===
> note this line
> 762.1     2  7                   CTLSEP = ' ';
> 762.1     2  7                   CTLECT = CTLECT + 1;
> 762.1     2  7                   PUT FILE (MSGPRT) EDIT
> 762.1                              ('Value is not within valid range')
> 762.1                              (SKIP, A);
> 762.1     2  7                 END;
> 762.1     2  6                 ELSE DO;
> 762.1     2  7                   K = CTLPIC;
> 762.1     2  7                   IF CTLSEP = '-' THEN
> 762.1     2  7                     DO J = J + 1 TO K;
> 762.1     2  8                       SEG_CNT =
> 762.1                                SEG_CNT + 1;
> 762.1     2  8                       SEG(J) = '1'B;
> 762.1     2  8                     END;
> 762.1     2  7                   ELSE
> 762.1     2  7                     DO J = K;
> 762.1     2  8                       SEG_CNT =
> 762.1                                SEG_CNT + 1;
> 762.1     2  8                       SEG(J) = '1'B;
> 762.1     2  8                     END;
> 762.1     2  7                   CTLSEP = SUBSTR(CTLVAL,I+1,1);
> 762.1     2  7                   IF CTLSEP ?= ',' & CTLSEP ?= '-' & CTLSEP
> ?= ' ' THEN D
> 762.1     2  7   O;                CTLSEP = ' ';
> 762.1     2  8                     CTLECT = CTLECT + 1;
> 762.1     2  8                     PUT FILE (MSGPRT) EDIT
> 762.1                                ('Invalid character')
> 762.1                                (SKIP, A);
> 762.1     2  8                   END;
> 762.1     2  7                   ELSE
> 762.1     2  7                     CTLVAL = SUBSTR(CTLVAL,I+2);
> 762.1     2  7                 END;
> 762.1     2  6               END;
> 762.1     2  5             END;
> 764.1          0

/********************************************************/
Quote:
> 765.1            /*            Begin Mod for Emb. Statute Cites
*/
> 766.1

/********************************************************/

- Show quoted text -

Quote:
> 767.1     2  4 0         END;

> The partial solution was to run the source through the compiler twice:
first
> with OPTIONS=MACRO, NOCOMPILE, MDECK, NOSYNTAX to produce a source deck
with
> the macro expanded; then a second run to compile that source deck.  Now
the
> lines are all uniquely numbered.  That seems like a lot just to get proper
> line numbers. Plus, the messages are still confusing.  The messages both
now
> point to line 1524.1:
> IBM1099I W  1524.1     FIXED DEC(15,0) operand will be converted to FIXED
>                        BIN(31,0). Significant digits may be lost.
> IBM1099I W  1524.1     FIXED DEC(15,0) operand will be converted to FIXED
>                        BIN(31,0). Significant digits may be lost.

> Lines 1524.2 and 1525.1 turn out to be:
> 1524.1,    2  6                 IF CTLPIC < LBOUND(SEG,1) |
> 1525.1     2  6                    CTLPIC > HBOUND(SEG,1) THEN DO;

> CTLPIC is declared  PIC '(15)9-' STATIC INIT (0);
> LBOUND and HBOUND return a FIXED BINARY (M,0) value.
> SEG is FIXED BIN(15).

> Greg



> > On Thu, 29 Nov 2001 13:21:10 -0500, in article

> > >Thanks for your response Daniel.  I'll reply one at a time to make them
> > >smaller, and because they won't be in order.

> > Seems a good idea. Let's do so.

> > >I'm not talking about the message here, rather about the line
numbering.
> In
> > >PL/I for MVS and VM, the listing has a number for each EXECUTABLE
> statement;
> > >but in VA PL/I the number is for each line in the source member.  There
> are
> > >advantages to BOTH methods; it depends on what you're doing at the
time.
> I'm
> > >just pointing out the disadvantage of this method when there's a macro
> that
> > >expands to a large number of statements.

> > Sorry, I do not have this problem. My compile listing shows every single
> line of
> > every macro. Do you have some  %noprint statements in some of your
macros?

> > -------------------------------------------------
> > With kind regards
> > Daniel Jacot
> > -------------------------------------------------
> > visit us at: http://www.winterthur.com



Mon, 24 May 2004 15:15:45 GMT  
 
 [ 32 post ]  Go to page: [1] [2] [3]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software