PLI limitation error at YGENSRC (showing different 2E pgms)

[Henky Saputera]

So we have an unbelievably large EXCEXTFUN monster. It is one of the oldest in the shop. It’s been regenerated/recompiled flawlessly countless times since the beginning of time until a few days ago…

The YGENSRC job now just died without generating any COBOL source (yes, we are a 2E COBOL shop…). The YGENSRC joblog shows some PLI limitation errors (i.e: PLI0485, PLI1601, PLI9001).

We’ve been trying to reduce the size of the function by externalizing some of the smaller pieces here and there. But we haven’t been successful in getting that ungodly EXCEXTFUN to generate… :mad:

What’s interesting here is that I notice there are at least 3 different 2E shipped programs when we tried different things (all ended up with the same PLI limitation error).

1)
YEXPACPR1I (Expand access path.)

MCH2804 Escape 40 03/14/12 21:47:38.289544 #somodx 002CA8 QPESGDYN QSYS 004C
Message . . . . : Tried to go larger than storage limit for object &1.
PLI0485 Information 00 03/14/12 21:47:38.289724 QPESERR QSYS 0154 YEXPACPR1I Y2SY 1EF3
Message . . . . : STORAGE condition raised at 2009 in YEXPACPR1I. ONCODE
8085.
Cause . . . . . : Either an ALLOCATE statement or your STATIC or AUTOMATIC
variables have requested additional storage and there is not enough storage
available. Recovery . . . : If an ALLOCATE statement was used, provide
additional storage by using the FREE statement for a based variable that
your program is no longer using. Otherwise, attempt to reduce the amount of
STATIC or AUTOMATIC storage used by your programs in the run-unit.
PLI1601 Information 00 03/14/12 21:47:38.289762 QPESERR QSYS 0154 YEXPACPR1I Y2SY 1EF3
Message . . . . : ERROR condition at 2009 in YEXPACPR1I. ONCODE 8085.
Cause . . . . . : A condition was raised for which no active on-unit for the
condition was found in the run unit. Recovery . . . : Refer to the
previous PL/I message to determine the original condition. Either eliminate
the original condition or change the program to ensure that an active
on-unit exists for the condition.
PLI9001 Escape 40 03/14/12 21:47:38.315229 YCRTOBJR3C Y2SY 0129 QCMD QSYS 01C8
Message . . . . : Run-unit ended at 2009 in YEXPACPR1I.
Cause . . . . . : The run-unit was stopped because of reason 3 in the
following list: (1) No active ERROR on-unit was found. (2) An ON ERROR was
specified for the ERROR condition. (3) An ON ERROR SYSTEM was specified for
the ERROR condition. (4) A normal return was tried from an ERROR on-unit.
(5) A STOP statement or a call to PLIDUMP with the stop (S) option was run.
Recovery . . . : Create a new ERROR on-unit (reason 1) or change the
existing ERROR on-unit (reasons 2, 3 or 4) so that it has a GOTO statement
specifying the statement where your program is to continue running. Create
your program again. For reason 5, omit the STOP statement or S option and
create your program again.

2)
YCHKTKNR1I (Determine if token is new for type R 7.0)

MCH2804 Escape 40 03/14/12 12:53:51.362858 #somodx 002CA8 QPESGDYN QSYS 004C
Message . . . . : Tried to go larger than storage limit for object &1.
PLI0485 Information 00 03/14/12 12:53:51.363057 QPESERR QSYS 0154 YCHKTKNR1I Y2SY 0132
Message . . . . : STORAGE condition raised at 49 in YCHKTKNR1I. ONCODE 8085.
Cause . . . . . : Either an ALLOCATE statement or your STATIC or AUTOMATIC
variables have requested additional storage and there is not enough storage
available. Recovery . . . : If an ALLOCATE statement was used, provide
additional storage by using the FREE statement for a based variable that
your program is no longer using. Otherwise, attempt to reduce the amount of
STATIC or AUTOMATIC storage used by your programs in the run-unit.
PLI1601 Information 00 03/14/12 12:53:51.363088 QPESERR QSYS 0154 YCHKTKNR1I Y2SY 0132
Message . . . . : ERROR condition at 49 in YCHKTKNR1I. ONCODE 8085.
Cause . . . . . : A condition was raised for which no active on-unit for the
condition was found in the run unit. Recovery . . . : Refer to the
previous PL/I message to determine the original condition. Either eliminate
the original condition or change the program to ensure that an active
on-unit exists for the condition.
PLI9001 Escape 40 03/14/12 12:53:51.382305 YCRTOBJR3C Y2SY 0129 QCMD QSYS 01C8
Message . . . . : Run-unit ended at 49 in YCHKTKNR1I.
Cause . . . . . : The run-unit was stopped because of reason 3 in the
following list: (1) No active ERROR on-unit was found. (2) An ON ERROR was
specified for the ERROR condition. (3) An ON ERROR SYSTEM was specified for
the ERROR condition. (4) A normal return was tried from an ERROR on-unit.
(5) A STOP statement or a call to PLIDUMP with the stop (S) option was run.
Recovery . . . : Create a new ERROR on-unit (reason 1) or change the
existing ERROR on-unit (reasons 2, 3 or 4) so that it has a GOTO statement
specifying the statement where your program is to continue running. Create
your program again. For reason 5, omit the STOP statement or S option and
create your program again.

3)
YMSGACTE1I (YEDTMDL Edit message action diagram.) – this one appeared when I attempted to add a very large subroutine construct to the 2E notepad (option NA/NR). I was thinking to wrapperize this very large subroutine. But I ended up with the same PLI limitation error. When I checked the notepad, I saw that it only contained the first few sections of the subroutine, the rest of the codes wasn’t there.

STORAGE condition raised at 797 in YMSGACTE1I. ONCODE 8085.

                        Additional Message Information                        
                                                                              
Message ID . . . . . . :   PLI0485       Severity . . . . . . . :   00        
Message type . . . . . :   Information                                        
Date sent  . . . . . . :   03/14/12      Time sent  . . . . . . :   21:14:39  
                                                                              
Message . . . . :   STORAGE condition raised at 797 in YMSGACTE1I. ONCODE     
  8085.                                                                       
Cause . . . . . :   Either an ALLOCATE statement or your STATIC or AUTOMATIC  
  variables have requested additional storage and there is not enough storage 
  available.                                                                  
Recovery  . . . :   If an ALLOCATE statement was used, provide additional     
  storage by using the FREE statement for a based variable that your program  
  is no longer using. Otherwise, attempt to reduce the amount of STATIC or    
  AUTOMATIC storage used by your programs in the run-unit.                    

I’m wondering if any of these 2E internal programs might contain some hints on which area we should be looking to avoid the PLI limitation error of the YGENSRC. Also any useful tip to get around this frustrating issue is greatly appreciated...

Thanks so much.

[Anon Anon]

Personally I'd raise an issue with CA.

However, when things have been okay for years and years and there has been no real change then I also look at the potential for a model corruption.

Consider the YCHKMDL command and also the deleting and recreation of the 2E table space. Unfortunately I am at home so don't have access right now to help with specifics but I'd look in these areas.

Lastly, if it is a limitation error then sometines generating the program interactively with the 'G' option rather that the traditional 'J' and submit build often shows the exact step that is failing.

I hope that this helps in the meantime, or until Crispin is online.

Lee.

[Deactivated User]

leed wrote:

I hope that this helps in the meantime, or until Crispin is online.

Lee.

That made me laugh :)

[Henky Saputera]

I appreciate everyone's replies and comments... Thank you all so much.

Lee -- yes we've been running that YCHKMDL and YDLTOBJTBL. Related to option G (not J), I just learned a pretty cool trick shared by someone. So the generated source can still be found in QTEMP in file YGENSRCRFP. This is one of the reasons why I love this forum, there are still cool stuff to be picked up here and there even though one has many years of experience in using 2E...

Crispin -- we are also at 8.5 1351. Cool tip there about the recommended value of YGENLMT. Thanks for this...

Simon -- so it turned out that one of our colleagues has opened up a new ticket 20860714-1 (YGENSRC MCH2804 YCHKTKNR1I 49). Definitely if there's an existing hotfix out there, it will be very desirable. Our short term here is to break down the function into smaller pieces. Another colleague found out that the issue had something to do with parameter variable-naming assignment. So there are 6 calls to another program, and this one program has countless parameters. When one of the 6 calls was commented out, the function seemed to be able to generate/compile. Some experiment to get around this parameter limitation will still need to be done. One of them is by wrapping that other program inside a new EXCINTFUN with turned on Generate as Subroutine & Share Subroutine. We'll see how this turns out...

Thanks again.

Best Regards,

Henky

[Anon Anon]

Hi,

Approximately 18 months ago, coding modifications were made for Problem C22E 239. These modifications were massive as they affected many,
many programs and were made as a proto-type and a proof-of-concept for development of the r8.6 release. Coding modifications for Problem C22E 239
was an ongoing effort that spanned many months.

Crispin is correct to state that coding modifications were made for C22E 239, in fact, Crispin assisted us with the initial testing for which we are extremely
grateful to Crispin for (Thank You again Crispin) . However, I failed to make it clear to Crispin that these modifications were not a Test Fix, per se, for r8.5.
Thus, these modifications are not available as a Test Fix for a r8.5 environment. I’m sorry for this miscommunication and/or inconvenience that this may have
caused.

Please note that this development approach enabled us to do massive code changes while optimizing the coverage of testing for such modifications.
These modifications had been implemented many months prior to the Alpha/Beta testing cycles for the r8.6 release.

As always, so as not to mismanage customer expectations, the 2E team does not guarantee the date nor content of any future release of CA 2E.


Thanks,
Mark


Mark Ronayne
CA Technologies
Senior Software Engineer
Tel: [phone]
Fax: [phone]
[e-mail]

[Deactivated User]

Hi Mark,

Thanks for clarifying things.

My apologies to everyone for getting their hopes up. Still, yet one more good reason to upgrade to 8.6 when it becomes available (assuming this indeed makes it into the GA code).

Crispin.

[Anon Anon]

Hi,

Now that CA 2E r8.6 is available by electronic download on Support.ca.com, we can officially state that the coding modifications that were made
for Problem C22E 239 are, in fact, included within CA 2E r8.6.


Thanks,
Mark


Mark Ronayne
CA Technologies
Senior Software Engineer
Tel: [phone]
Fax: [phone]
[e-mail]

[Deactivated User]

Hi Mark,

Good news indeed :)

Crispin.

[Henky Saputera]

Mark, this C22E 239 fix (as part of 2E 8.6), is it going to fix or related in anyway to issue # 20860714-1 (YGENSRC MCH2804 YCHKTKNR1I 49)? Do you know?

Thanks.

MarkRonayne wrote:

Now that CA 2E r8.6 is available by electronic download on Support.ca.com, we can officially state that the coding modifications that were made
for Problem C22E 239 are, in fact, included within CA 2E r8.6.

[Anon Anon]

Hello Henky,

Thank you for posting your inquiry in regards to C22E 239 and Issue 20860714-1 (YGENSRC MCH2804 YCHKTKNR1I 49).

Within our Generators, we use PL/I structures to store needed tokens (names & values). It is during this allocation of memory, that the YCHKTKNR1I program
is failing due to the IBM imposed 16MB limitation. There simply is not enough memory available in order to allocate additional memory.

I have reviewed Issue 20860714-1 and my understanding is that the EXCEXTFUN function is extremely large, thus, the 16MB limitation is being breached during
the generation of that function (even when that is the only function being submitted for generation).

Modifications made for C22E 239 include the freeing of memory that had previously been allocated which was no longer needed within the PL/I run unit.
Thus, prior to the modifications made for C22E 239, when submitting many files/functions for generation the 16MB limit was being reached, however,
if the same list of submissions was split into multiple jobs, the generation was then successful. Now with r8.6, with the modifications for C22E 239 in place,
the ability to submit many files/functions for generation within the same job has a much higher chance for a successful job completion
(without encountering the 16MB limitation).

Your question to me: "Do you know?"
This is a hard question for me to answer definitively. Theoretically, it is 'possible' that the modifications made for C22E 239 are now freeing enough memory
(that was not previously being freed) to now allow the extremely large function to generate successfully. However, being that my understanding is that the
16MB limitation was being reached when only that one extremely large function was being generated, then I believe that it is less likely that the C22E 239
modifications will now allow this extremely large function to generate successfully.

If you like, you can provide me with a copy of your model (or a subset of your model which includes the extremely large function) and I can try the generation
here using r8.6 and let you know the results.


Thanks,
Mark


Mark Ronayne
CA Technologies
Senior Software Engineer
Tel: [phone]
Fax: [phone]
[e-mail]

[Anon Anon]

MarkRonayne wrote:

Hello Henky,

Thank you for posting your inquiry in regards to C22E 239 and Issue 20860714-1 (YGENSRC MCH2804 YCHKTKNR1I 49).

Within our Generators, we use PL/I structures to store needed tokens (names & values). It is during this allocation of memory, that the YCHKTKNR1I program
is failing due to the IBM imposed 16MB limitation. There simply is not enough memory available in order to allocate additional memory.

I have reviewed Issue 20860714-1 and my understanding is that the EXCEXTFUN function is extremely large, thus, the 16MB limitation is being breached during
the generation of that function (even when that is the only function being submitted for generation).

Modifications made for C22E 239 include the freeing of memory that had previously been allocated which was no longer needed within the PL/I run unit.
Thus, prior to the modifications made for C22E 239, when submitting many files/functions for generation the 16MB limit was being reached, however,
if the same list of submissions was split into multiple jobs, the generation was then successful. Now with r8.6, with the modifications for C22E 239 in place,
the ability to submit many files/functions for generation within the same job has a much higher chance for a successful job completion
(without encountering the 16MB limitation).

Your question to me: "Do you know?"
This is a hard question for me to answer definitively. Theoretically, it is 'possible' that the modifications made for C22E 239 are now freeing enough memory
(that was not previously being freed) to now allow the extremely large function to generate successfully. However, being that my understanding is that the
16MB limitation was being reached when only that one extremely large function was being generated, then I believe that it is less likely that the C22E 239
modifications will now allow this extremely large function to generate successfully.

If you like, you can provide me with a copy of your model (or a subset of your model which includes the extremely large function) and I can try the generation
here using r8.6 and let you know the results.


Thanks,
Mark


Mark Ronayne
CA Technologies
Senior Software Engineer
Tel: [phone]
Fax: [phone]
[e-mail]

Sounds like a classic case of looking at the program and breaking it down a little. My experience tells me that when internal limits are met (and I know the product designers regardless of product would have put very reasonable limits in place, in this case IBM), then it may be time to refactor.

Lee.

[Henky Saputera]

Mark, thanks for the detail info on C22E 239. After reading your explanation, I agree with you that the fix has very little likelihood of solving our issue Issue 20860714-1.

Our problematic EXCEXTFUN here has nothing fancy in it. It just has tons and tons of Move statements from variables to variables. Some developers who are more familiar with the function, took some time to review and eventually discovered certain obsolete sections that could be commented out. This resulted in huge savings of variables to be generated, thus, a successful regeneration/recompilation.

Again, I appreciate everyone's feedback on this topic.

[Anon Anon]

Hi Henky,

Thanks for the update, it is very much appreciated.

I will be out of the office all of next week, however, if there are further
questions/comments, I will be happy to address them upon my return.


Thanks,
Mark

[Deactivated User]

Hi Henky,

What release of 2E are you on?

If you're at 8.5 then contacting CA may be a good idea, as there is a hotfix that might address this. It is quite a large change, but it addresses quite a few areas of tool failure due to memory issues. I have gone from YGENSRC jobs that were failing with large functions (we had our YGENLMT Model Value set to 80 because YGENSRC would fail if any large function were in it and we had any more than 80 functions in the YGENSRC job), to being able to process YGENSRC jobs with thousands (6500) of functions being generated. So it is a huge improvement in reducing the limitations.

Crispin.

[DONALD BURDETTE]

What PTF level is that? We are at 8.5 1351.

Thanks,

Donald Burdette
IT Manager
Payroll People, Inc.
559-251-9060 x. 290

From: CA Plex CA 2E Global User Community [mailto:[e-mail]]
Sent: Thursday, March 15, 2012 5:10 AM
To: [e-mail]
Subject: [CA 2E General Discussion] RE: PLI limitation error at YGENSRC (showing different 2E pgms)

Hi Henky,

What release of 2E are you on?

If you're at 8.5 then cantacting CA may be a good idea, as there is a hotfix that might address this. It is quite a large change, but it addresses quite a few areas of tool failure due to memory issues. I have gone from GEN jobs that were failing with large functions (we had our YGENLMT Model Value set to 80 because YGENSRC would fail if any large function were in it and we had any more functions in the YGENSRC job), to being able to process YGENSRC jobs with thousands on functions being generated. So it is a huge improvement in reducing the limitations.

Crispin.
Posted by:Crispin
--
CA Communities Message Boards
97686362
[e-mail]<mailto:[e-mail]>
http://communities.ca.com

________________________________
If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of the communication is strictly prohibited. If you have received this communication in error, please notify us by telephone immediately and delete the original message.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, we inform you that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

[Deactivated User]

Don,

I'm at the same PTF level, 1351. The hotfix is just that, a hotfix. You will need to contact CA Support to get hold of it...

The hotfix # is YC22E239.

Crispin.

[Simon_Cockayne]

Hey Don,

Here's a link to the Problem Document that Crispin is referring to:

https://support.ca.com/irj/portal/kbproblem?docid=530033&productcd=C22E&problemnbr=239&fromKBResultsScreen=T

Cheers,

Simon

Simon Cockayne
CA Technologies
Principal Software Engineer
CA Subject Matter Expert
Tel: [phone]
[e-mail]

[DONALD BURDETTE]

Thanks!

Donald Burdette
IT Manager
Payroll People, Inc.
559-251-9060 x. 290

From: CA PLEX CA 2E Global User Community [mailto:[e-mail]]
Sent: Thursday, March 15, 2012 8:21 AM
To: [e-mail]
Subject: RE: [CA 2E General Discussion] RE: PLI limitation error at YGENSRC (showing

Hey Don,

Here's a link to the Problem Document that Crispin is referring to:

https://support.ca.com/irj/portal/kbproblem?docid=530033&productcd=C22E&problemnbr=239&fromKBResultsScreen=T

Cheers,

Simon

Simon Cockayne
CA Technologies
Principal Software Engineer
CA Subject Matter Expert
Tel: [phone]
[e-mail]<mailto:[e-mail]>
--
CA Communities Message Boards
97688121
[e-mail]<mailto:[e-mail]>
http://communities.ca.com

________________________________
If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of the communication is strictly prohibited. If you have received this communication in error, please notify us by telephone immediately and delete the original message.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, we inform you that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

[Simon_Cockayne]

Hi Henky,

Wonderful advice from Lee and Crispin.

It never ceases to warm my heart that we have so many kind and generous people here in the 2E community who are willing so spend the time, which is so precious these days, to help out a fellow 2E adventurer.

I would start with YCHKMDL and then deleting the user space.

If deleting the user space does not solve the problem, I would raise an issue with CA Support.

Please do confirm what release (and any service pack and Test Fixes you are using).

In the event that we do not have a Test Fix for your release, you may also want to consider providing your model CA Support...and they can verify whether the latest release would solve the problem.

Typically the latest release has the best peformance, highest capacities and least restrictions.

Cheers,

Simon

Simon Cockayne
CA Technologies
Principal Software Engineer
CA Subject Matter Expert
Tel: [phone]
[e-mail]

[Henky Saputera]

Some update on this topic, as I'd like to share our finding... So the same program ended up with source-generation error again. This time, YEXPACPR1I was shown in the joblog.

After trial and error, we found out that the error has something to do with how many data-structures generated for the called programs. If the parameter entry of called program is defined as either KEY or RCD, this will become a data structure named "xxRC." (note: xx is some alphabetical value assigned during source generation). We learned that around high 60s to low 70s of these DSs, the function would end up with the generation error.

So we changed some of the called functions's parameter list to start using FLD. When the number of DSs generated drops to low 60s, the function can be generated/compiled successfully.

So now knowing this, we know how to resolve when similar issue reoccurs. Hopefully, this can be helpful as well for others...

Thanks.

henky.sap wrote:

So we have an unbelievably large EXCEXTFUN monster. It is one of the oldest in the shop. It’s been regenerated/recompiled flawlessly countless times since the beginning of time until a few days ago…

The YGENSRC job now just died without generating any COBOL source (yes, we are a 2E COBOL shop…). The YGENSRC joblog shows some PLI limitation errors (i.e: PLI0485, PLI1601, PLI9001).

We’ve been trying to reduce the size of the function by externalizing some of the smaller pieces here and there. But we haven’t been successful in getting that ungodly EXCEXTFUN to generate… :mad:

What’s interesting here is that I notice there are at least 3 different 2E shipped programs when we tried different things (all ended up with the same PLI limitation error).

1)
YEXPACPR1I (Expand access path.)

[Deactivated User]

Hi Henky,

Thanks for sharing!

This got me curious. I created a suite of 10 functions all with 9 parameters being passed as RCD. Added the calls in an EXCEXTFUN and it generated just fine.

So it seems that there has to be some other factor. Good to know though, incase it comes up in the future!

Crispin.

[Henky Saputera]

Hi Crispin,

Yes, I'm suspecting that there must be some other factors involved. If we think of it, a function calls 10 other functions with all RCD parm entries (~90 DSs) should not be a big deal...

But it did make a big difference in our case. Maybe whatever the temporary holder (ex: userspace or 2E object table ??) is shared for various purposes during the source generation, and this has a max threshold(??), I don't know... We start seeing various generation/compilation issues on some of the very enormous functions we have here.

Thanks.

[Anon Anon]

Hello Henky,

Thank you for posting your update. Good to hear that you were able to find a work around to successfully generate/compile your extremely large EXCEXTFUN function.

Curious, are you currently using r8.5 1351? Or did you upgrade to r8.6 GA?

If you are using r8.6 GA, we would very much appreciate it if you would open an Issue for this reported problem while providing us with your Model
(so that we would then be able to do problem determination).

Thank you for any assistance that you are able to provide us regarding this and we are sorry for any inconvenience that this YGENSRC error has caused you.


Thanks,
Mark


Mark Ronayne
CA Technologies
Senior Software Engineer
Tel: [phone]
Fax: [phone]
[e-mail]

[Henky Saputera]

Hi Mark,

Yes, we are still at r8.5 1351. We're thinking to go 8.6, but this won't happen until sometime mid-year next year most likely...

Regards.