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

Hi Group,

wondering, if anybody out there already moved her/his whole
application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
willing to share her/his experiences...

Especially is my question about assembler programs calling VA PL/I
routines, as we encounter problems (PL/I abending), even if we build a
correct LE environment (at least we think so)

Every hint and help is welcome
Alexander



Thu, 13 May 2004 18:55:54 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Alexander Eller writes ...

Quote:
>Hi Group,

>wondering, if anybody out there already moved her/his whole
>application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
>willing to share her/his experiences...

>Especially is my question about assembler programs calling VA PL/I
>routines, as we encounter problems (PL/I abending), even if we build a
>correct LE environment (at least we think so)

>Every hint and help is welcome
>Alexander

Alexander,

We offer a three day course on "Visual Age PL/I Differences". However, it is
more concerned with explaining the new features of the language than the
conversion process. Details of the course are at:
http://www.trainersfriend.com/e204descr.htm

In addition, we have a three day course about using LE (in fact, this is one of
the courses IBM sent their LE level 2 support to several years ago). Again, it
is more about understanding than migrating, but that might be a step in the
right direction. Details about this course are found at:
http://www.trainersfriend.com/m212descr.htm

Aside from that, if you can post details of your problems as you encounter
them, there is a reasonable chance that someone on this newsgroup can help.

Good luck,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Thu, 13 May 2004 22:42:18 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Quote:

>wondering, if anybody out there already moved her/his whole
>application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
>willing to share her/his experiences...

You talk about a interesting topic.

I have a question which is related to the topic:

It is right, that you have to recompiled all fetch modules when
you move from OS/VS PL/1 to VA PL/1?

mfg: Jochen Schmitt



Fri, 14 May 2004 06:26:25 GMT  
 Migrating from OS/VS PL/I to VA PL/I
On 25 Nov 2001 02:55:54 -0800, in article

Quote:

>Hi Group,

>wondering, if anybody out there already moved her/his whole
>application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
>willing to share her/his experiences...

>Especially is my question about assembler programs calling VA PL/I
>routines, as we encounter problems (PL/I abending), even if we build a
>correct LE environment (at least we think so)

>Every hint and help is welcome
>Alexander

Did you use CEEFETCH? AFAIK, this is the only possibility to load a DLL from an
ASSEMBLER program, and this program must be LE enabled. Note that VA PL/I
routiness are DLLs by default.

Maybe you could compile the PL/I programs NORENT and LIMITS(EXTNAME(8)).
According to the most current documentation (APARs PQ52000 and PQ54237), VA PL/I
programs are 'old style' if you use these compiler options and have the old
restrictions (no FETCH from a fetched module, no external variables, no file
sharing, no controlled variables). Since now, I did never try to call such a
module from ASSEMBLER.

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



Fri, 14 May 2004 17:00:17 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Quote:
Daniel Jacot writes...
>On 25 Nov 2001 02:55:54 -0800, in article

>>Hi Group,

>>wondering, if anybody out there already moved her/his whole
>>application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
>>willing to share her/his experiences...

>>Especially is my question about assembler programs calling VA PL/I
>>routines, as we encounter problems (PL/I abending), even if we build a
>>correct LE environment (at least we think so)

>>Every hint and help is welcome
>>Alexander

>Did you use CEEFETCH? AFAIK, this is the only possibility to load a DLL from
>an
>ASSEMBLER program, and this program must be LE enabled. Note that VA PL/I
>routiness are DLLs by default.

>Maybe you could compile the PL/I programs NORENT and LIMITS(EXTNAME(8)).
>According to the most current documentation (APARs PQ52000 and PQ54237), VA
>PL/I
>programs are 'old style' if you use these compiler options and have the old
>restrictions (no FETCH from a fetched module, no external variables, no file
>sharing, no controlled variables). Since now, I did never try to call such a
>module from ASSEMBLER.

You can call DLLs from LE-enabled Assembler, and we discuss how to do that in
our class "Inter-Language Communication in OS/390". For details about the
course, see ...

http://www.trainersfriend.com/m220descr.htm

Kind regards,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Sat, 15 May 2004 02:28:16 GMT  
 Migrating from OS/VS PL/I to VA PL/I
The assembler interface has changed from OS PL/I (this is LE-, rather than
PL/I-driven). You will need to modify all such routines. Note that PL/I ->
Assembler remains easier than the other direction, which has never been
trivial.

Take a look at the LE docs (e.g. for z/OS V1R2.0, this is under
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/CEE2BK10) under
"Writing ILC applications", in chapter 14 (Communicating between Assembler
and HLLs). The LE Programming Guide also contains information on this topic.

If you're not on this version (you gailed to indicate your z/OS / OS/390
version) the search
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves?filter=l...
+environment will get you to all LE versions.

You'll also find all of this on your z/OS / OS/390 Documentation Collection
CDs


Quote:
> Hi Group,

> wondering, if anybody out there already moved her/his whole
> application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
> willing to share her/his experiences...

> Especially is my question about assembler programs calling VA PL/I
> routines, as we encounter problems (PL/I abending), even if we build a
> correct LE environment (at least we think so)

> Every hint and help is welcome
> Alexander



Sat, 15 May 2004 15:12:54 GMT  
 Migrating from OS/VS PL/I to VA PL/I
I meant to also point out the poster should look up the compile optin DLLINIT;
it may well have an influence on how to create PL/I subroutines.

Kind regards,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Sat, 15 May 2004 21:32:30 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Why would one want to do that?  It's not a rhetorical question.  I need a
real-world answer.

 I am involved in an effort to "evaluate" VA PL/I for OS/390 V2.R2.M1.  To
this end I am re-compiling a fairly complex application which is now in
production having been compiled with PL/I for MVS & VM, V1.R1.M1.  (It also
has elements written in C and ASM, although I'm pretty sure there is no ASM
calling PL/I.)  The pain is excruciating!  I want to recommend against
switching to VA PL/I, but I don't have a good understanding of the
advantages/disadvantages of VA PL/I versus PL/I for MVS & VM. (The bit about
what fetched modules can do is not significant for this application.)

 One question that has been raised in my shop is about the future of  PL/I
for MVS & VM.  Not so much, "Should we embrace VA PL/I?" but more along the
lines of, "Must we at some point in time move off of PL/I for MVS & VM?"
Has there been an announcement regarding the imminent demise of PL/I for MVS
& VM?

Greg


Quote:
> Hi Group,

> wondering, if anybody out there already moved her/his whole
> application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
> willing to share her/his experiences...

> Especially is my question about assembler programs calling VA PL/I
> routines, as we encounter problems (PL/I abending), even if we build a
> correct LE environment (at least we think so)

> Every hint and help is welcome
> Alexander



Sat, 15 May 2004 22:37:44 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Quote:

> real-world answer.

>  I am involved in an effort to "evaluate" VA PL/I for OS/390 V2.R2.M1.  To
> this end I am re-compiling a fairly complex application which is now in
> production having been compiled with PL/I for MVS & VM, V1.R1.M1.  (It also
> has elements written in C and ASM, although I'm pretty sure there is no ASM
> calling PL/I.)  The pain is excruciating!  I want to recommend against
> switching to VA PL/I,

What are the problems?
Quote:
> but I don't have a good understanding of the
> advantages/disadvantages of VA PL/I versus PL/I for MVS & VM. (The bit about
> what fetched modules can do is not significant for this application.)

>  One question that has been raised in my shop is about the future of  PL/I
> for MVS & VM.  Not so much, "Should we embrace VA PL/I?" but more along the
> lines of, "Must we at some point in time move off of PL/I for MVS & VM?"
> Has there been an announcement regarding the imminent demise of PL/I for MVS
> & VM?

> Greg



> > Hi Group,

> > wondering, if anybody out there already moved her/his whole
> > application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
> > willing to share her/his experiences...

> > Especially is my question about assembler programs calling VA PL/I
> > routines, as we encounter problems (PL/I abending), even if we build a
> > correct LE environment (at least we think so)

> > Every hint and help is welcome
> > Alexander



Sun, 16 May 2004 07:36:57 GMT  
 Migrating from OS/VS PL/I to VA PL/I
The port is "mostly harmless" [to quote Douglas Adams].

There are some gripes (e.g. change in behaviour in normal return from ON
SIZE - I've actually opened a PMR on this one), but usually its a fairly
simple migration.

ILC with C / C++ is easy, once you understand how LE deals with it, but
since PL/I for MVS & VM has the same issue (unlike OS PL/I) you should have
solved that already. Assembler calls from PL/I are also fairly easy (again,
once you've dealt with LE). Assembler calling PL/I, like any foreign calls,
absolutely requires you to understand LE, and there is no OS PL/I-like
compatibility interface. OTOH, you can study this problem in a test program.

The main reason to move is the same as the reason you moved from OS PL/I to
PL/I for MVS & VM. Its where new things happen. If you're developing, you'll
want to move. If your environment is frozen, why bother?


Quote:
> Why would one want to do that?  It's not a rhetorical question.  I need a
> real-world answer.

>  I am involved in an effort to "evaluate" VA PL/I for OS/390 V2.R2.M1.  To
> this end I am re-compiling a fairly complex application which is now in
> production having been compiled with PL/I for MVS & VM, V1.R1.M1.  (It
also
> has elements written in C and ASM, although I'm pretty sure there is no
ASM
> calling PL/I.)  The pain is excruciating!  I want to recommend against
> switching to VA PL/I, but I don't have a good understanding of the
> advantages/disadvantages of VA PL/I versus PL/I for MVS & VM. (The bit
about
> what fetched modules can do is not significant for this application.)

>  One question that has been raised in my shop is about the future of  PL/I
> for MVS & VM.  Not so much, "Should we embrace VA PL/I?" but more along
the
> lines of, "Must we at some point in time move off of PL/I for MVS & VM?"
> Has there been an announcement regarding the imminent demise of PL/I for
MVS
> & VM?

> Greg



> > Hi Group,

> > wondering, if anybody out there already moved her/his whole
> > application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
> > willing to share her/his experiences...

> > Especially is my question about assembler programs calling VA PL/I
> > routines, as we encounter problems (PL/I abending), even if we build a
> > correct LE environment (at least we think so)

> > Every hint and help is welcome
> > Alexander



Sun, 16 May 2004 15:45:11 GMT  
 Migrating from OS/VS PL/I to VA PL/I
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.

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.

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!

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.

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.
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.

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.

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.

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.

And it goes on...

Greg


to do that?  It's not a rhetorical question.  I need a

Quote:
> > real-world answer.

> >  I am involved in an effort to "evaluate" VA PL/I for OS/390 V2.R2.M1.
To
> > this end I am re-compiling a fairly complex application which is now in
> > production having been compiled with PL/I for MVS & VM, V1.R1.M1.  (It
also
> > has elements written in C and ASM, although I'm pretty sure there is no
ASM
> > calling PL/I.)  The pain is excruciating!  I want to recommend against
> > switching to VA PL/I,

> What are the problems?

> > but I don't have a good understanding of the
> > advantages/disadvantages of VA PL/I versus PL/I for MVS & VM. (The bit
about
> > what fetched modules can do is not significant for this application.)

> >  One question that has been raised in my shop is about the future of
PL/I
> > for MVS & VM.  Not so much, "Should we embrace VA PL/I?" but more along
the
> > lines of, "Must we at some point in time move off of PL/I for MVS & VM?"
> > Has there been an announcement regarding the imminent demise of PL/I for
MVS
> > & VM?

> > Greg



> > > Hi Group,

> > > wondering, if anybody out there already moved her/his whole
> > > application development from OS/VS PL/I V2.3 to VisualAge PL/I and is
> > > willing to share her/his experiences...

> > > Especially is my question about assembler programs calling VA PL/I
> > > routines, as we encounter problems (PL/I abending), even if we build a
> > > correct LE environment (at least we think so)

> > > Every hint and help is welcome
> > > Alexander



Mon, 17 May 2004 02:21:32 GMT  
 Migrating from OS/VS PL/I to VA PL/I

Quote:

> 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)).

Might be the result of arithmetic operation {addition, for example,
of two FIXED(10) operands will produce a FIXED(11) result}.

Quote:
> 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.

Are you _sure_ you have the appropriate manual?

I'll look at the others off-line.



Mon, 17 May 2004 07:31:34 GMT  
 Migrating from OS/VS PL/I to VA PL/I
On Wed, 28 Nov 2001 13:21:32 -0500, in article

Quote:

>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:

Please post your problems, so we all can learn. Maybe even IBM can ... &-)

Quote:
>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.

That looks really strange to me, too. All my manuals say that IBM1099 is the DO
LOOP thing. BTW, this messageis issued by the Optimizer, not by the Compiler.
Could you please give me the snippet of code that produces this message? I'd
like to try it out on my installation.

Quote:
>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.

I'd guess that the compiler points you to the correct line, the call to the
macro. It  (the Compiler, the Precompiler?) has to convert parameters in order
to resolve the macro.

Quote:
>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.

Quote:
>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.

Quote:
>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.

Quote:
>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.

Not sure, but according to the manual 'Explanation:  REGIONAL(2) and REGIONAL(3)
ENVIRONMENT options are    
syntax-checked during compile-time but are not supported during run-time.', I'd
try to remove this parameter.

Quote:
>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.
>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.

You may remove the declaration of the parameters in the DCL of the EXTERNAL
ENTRY.

Quote:
>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.

Say NEW,CATLG and you'll find the file since it is cataloged now. Another idea:
Do you have the 'full' version of BPXWDYN? This verson supports more keywords
than the default version. You may download it from
ftp://ftp.software.ibm.com/s390/zos/tools/bpxwdyn/bpxwdyn.unload

Quote:
>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.

The good stuff you loose is the possibility to CALL entries in DLLs whose names
are mixedcase and have more than 8 characters. You can CALL
My_Subroutine_which_is_able_to_allocate_files-dynamically instead of CALL
DYNALMOD. If you use DLL linkage. And if you intend to use such longnames.

Quote:
>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.

Compileusing the options GOSTMT and GONUMBER. The object code is a little bit
bigger, but the runtime is not affected. Code ON ERROR CALL PLIDUMP('TFCHB') in
your PL/I programs.

Quote:
>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.

This error occurs when the calling and the called program to not mach. It's an
internal LE error and should be translated to a meaningfull message by IBM.

Quote:
>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.

I am not aware of a limit of PUTs. I'd rather guess that you do not OPEN the
file SYSPRINT as you should. Be aware that every module and the main program do
DECLARE SYSPRINT in the same manner and code an OPEN statement to SYSPRINT into
every module. This should help.

Quote:
>And it goes on...

Go on, I am very interested in problems. If others are not, please post a
comment and I will communicate by mail instead of the User Group.

Quote:
>Greg

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


Mon, 17 May 2004 19:19:06 GMT  
 Migrating from OS/VS PL/I to VA PL/I
Thanks for your response Daniel.  I'll reply one at a time to make them
smaller, and because they won't be in order.

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.


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

> >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.

> I'd guess that the compiler points you to the correct line, the call to
the
> macro. It  (the Compiler, the Precompiler?) has to convert parameters in
order
> to resolve the macro.



Tue, 18 May 2004 02:21:10 GMT  
 Migrating from OS/VS PL/I to VA PL/I

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;


Quote:
> 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 02:22:47 GMT  
 
 [ 32 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. What is the difference between DEC PL/1 and OS/390 PL/1

2. VisualAge PL/I for OS/390 and PL/I 2.3

3. pl/1 vs. PL/I

4. PL/I vs. PL/1

5. OS/390 2.10 VA PL/I IVP COND CODE 0218

6. Current APAR of VA PL/I for OS/390

7. VA PL/I for OS/390: DLL questions

8. IBM's VA PL/1 for OS/2

9. VA PL/I for OS/390 - Free Manuals in PDF Format

10. OS/VS PL/I and assembler functions?

11. anyone migrated successfully to Enterprise PL/I?

12. anyone migrated successfully to Enterprise PL/I?

 

 
Powered by phpBB® Forum Software