在z/OS下,rexx和clists的相对优点是什么?

这是一个指向IBM的inofcenter的链接,概述了 REXX and CLIST

基本上,雷克斯是新的(大约15年),克莱斯特是老的(在我之前-我已经在它约30年)。大型机群体似乎越来越老了,许多建造ISPF平台的人在雷克斯上市之前就已经学会了他们的交易,所以我认为这只是“传统”(老狗,老把戏)的问题。

有一次,我相信IBM想让克莱斯特退休,转而支持雷克斯,但像大型机那样,在我的有生之年,任何事情都不会发生。

我发现clist中的大多数都与通过ispf面板管理ispf对话框相关。在这种类型的应用程序中使用一个应用程序没有优势。

我个人对Rexx的偏好是因为它是一种基本上更强大的语言,并且随z/OS一起提供,所以它总是可用的。此外,rexx在z/OS下的地址空间比clist(如tso甚至batch)多。它也可以在Windows下使用(请参见: Object REXX )。Windows版本基本上是z/OS版本的超集,只要保持非对象扩展并小心管理I/O,就可以在Windows框上运行与大型机上相同的exec。我已经构建了许多实用程序类型的函数,它们在大型机上和在Windows上一样容易运行——几乎没有变化(除了管理文件I/O的几行)。

与clist不同的是,rexx也能够进行一些严重的数据处理。我听说Z/OS下的Rexx应用程序的性能类似于在WebSphere下运行的Java(给定相同大小的CPU)。有时,我会在非常合理的时间内通过rexx例程处理多个千兆字节大小的数据文件。

不管怎样,我可以继续…我相信,在回答你的问题时,雷克斯基本上是一个更好的工具,能够做克莱斯特所能做的任何事情。clist的预防仅仅是程序员按照他们成长的方式做事,而不是学习新技术。

z/OS上的Rexx的好处在于,如果您需要很高的性能,您可以为此购买编译器和库,并获得接近本机代码的速度。

我没有一个完整的答案,只有一个想法。

我公司还使用clist,但我们也有rexx。

正如我所看到的:Rexx是一种新的更好的语言,但是在构建TSO应用程序时,clist仍然是首选的,它处理屏幕上的数据列表/数组。我甚至不知道Rexx处理屏幕上的列表/数组有多好。

我们只使用rexx来缩小类似脚本的程序。

当做 西格斯特德