每个内部会话，该限制为36个。 。 您真的还需要更多吗？

我不理解"从子例程池中删除生成的程序"，您对这些术语感到困惑，一个子例程池就是一个子例程池类型的程序。 您要删除生成的子例程池。

不，您不能删除生成的子例程池。

解决方法是创建一个新的内部会话。 我经常使用RFC用户会话的创建-这是内部会话的高级级别（重复CALL FUNCTION'Z ...'DESTINATION'NONE'->生成SUBROUTINE POOL ...多达36次-> CALL FUNCTION'RFC_CONNECTION_CLOSE' EXPORTING destination ='NONE'），以便全局创建超过36个子例程池。

编辑有关99K限制的信息（下面的文字摘自注释）：

您要做什么 说："生成程序时，PROGNAME具有下一个值：％_T0001A，％_ T0001B，...，％_ T0001Z，..，％_ T0002A，％_ T0002B，... ...计数不取决于用户会话。"

我的回答："您是对的。有趣。但是我获得60.466.176的可能性，而不是99.000（36 ^ 5，因为5个位置中的每个位置都有10个数字+ 26个拉丁字符），所以 您有1800到3000年的时间才能到达％_TZZZZZ。我无法测试创建％_TZZZZZ之后（可能是从％_T00000重新开始吗？）之后发生的情况，因为如果在一秒钟内生成100个子例程池，我应该 应该等待大约7天。

如果我重新启动应用程序服务器，则编号将从％_T00000重新开始。 因此，这意味着您最多有6000万代用户，而无需重新启动应用程序服务器。

有关信息，请注意 64201-临时子例程池的最大数量建议使用SUBMIT而不是我的" RFC NONE"建议。

也许值得一提的是， 正在谈论 GENERATE SUBROUTINE POOL ...

桑德拉·罗西感谢您的光临 注意。 您帮了我很多忙。

Serghij Razumnyi 您是对的 。 有趣。 但是我获得60.466.176的可能性（36 ^ 5，因为在5个位置中的每个位置都有10个数字+ 26个拉丁字符），因此您在1800年到3000年之间才能达到％_TZZZZZ。 我无法测试％_TZZZZZ创建后会发生什么（也许它是从％_T00000重新启动吗？），因为如果在一秒钟内生成100个子例程池，我应该等待大约7天。

如果重新启动 应用程序服务器，编号从％_T00000重新开始。 因此，这意味着您最多有6000万代用户，而无需重新启动应用程序服务器。

有关信息，请注意 64201-临时子例程池的最大数量建议使用SUBMIT而不是我的" RFC NONE"建议。

我重新启动服务器并看到 程序名称的哪个计数器重置为零。

有什么反馈意见或结论可以与未来的访问者（和我）分享吗？