客户提出个问题,说有个批导发送邮件程序,数量一多就dump,最多也就处理三十来条。
一个批导处理三十多条就dump,不应该啊,然后就去看了那个批导程序。
看到是发送时循环调用了一个Z function。
可能当时为了通用,用动态内表实现的。
CALL METHOD CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE "动态内表结构填充
EXPORTING
IT_FIELDCATALOG = GT_FIELDCAT
IMPORTING
EP_TABLE = DY_TABLE
EXCEPTIONS
GENERATE_SUBPOOL_DIR_FULL = 1
OTHERS = 2.
前几行也没事儿,到三十多行突然就发现DY_TABLE变成空了。
然后看了下里面:
这里subrc = 1。
具体啥意思一看也比较清楚了。
池子满了。
后来查了下,这个函数动态创建内表池子内最大数量是36.超过了就不能创建了。
要么换个其他方式动态实现,要么外面每次调用重开session,应该都能解决。
我比较懒。直接copy了一个这个函数。
运维嘛,尽量别影响其他原来的逻辑,copy个单独给这个批导使用影响最小嘛。
然后做了下面的调整。
定义了俩全局变量,一个是参考创建的字段fieldcat 一个是创建的动态内表。
因为一直循环调用,所以就是先判断是否参考创建的fieldcat一致,另外是否已经创建了动态内表。
如果不满足,重新创建,如果已经满足了,直接用用得了。
这个算是改动最小的,当然还可以变通,比如可能参考多个不同结构,也可以类似的处理嘛。只要不超过36个就行。
同一个问题解决方法很多,怎么影响最小,怎么简单怎么来呗。
领取专属 10元无门槛券
私享最新 技术干货