|
查看上一个主题 :: 查看下一个主题
|
| 作者 |
信息 |
dbzTHEdinosauer
全球主持人
已加入：2006年10月20日
帖子：6967
位置：瓷宝座
|
|
|
|
我想知道多少
pic9（n）显示
领域有？ |
|
| 回到顶部 |
|
 |
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
| dbzTHEdinosauer写道： |
我想知道多少
pic9（n）显示
领域有？ |
我没有预测。我预测这165个字节中的每一个都是一段文本，在某些情况下，它可能已被拆分为第二个项目，并且要将它们与原始文本进行比较，您需要将它们重新组合在一起。所有原件都放在一张巨大的桌子上，所有可能分开的桌子都放在另一张桌子上。
他们称我为Mindreader。好吧，听起来像是这样。
对于“分裂”，它是过时的。莎士比亚使用了它。在19世纪末期仍在使用。
Kunal Jain，您想告诉我们更多有关您的任务的信息吗？如果这是全部，那么您肯定不需要两个80meg表。 |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
| 库纳尔·贾恩写道： |
基本上，我需要比较两个VSAM文件的记录。
从某种意义上说，这种比较有点复杂
1.我需要忽略一些可接受的差异
2.记录有一个。项目密钥b。商品描述。一个项目密钥可能包含以序号区分的描述字符。
3.项目密钥在两个文件中的描述不是顺序。因此，为了比较项目键的所有描述，我打算将它们存储在两个内部表中。然后我打算检查一个项目键，如果第二个表（任何地方）中都没有第一个表的每个描述，如果第二个表中不存在第一个表的描述，它将作为删除的描述输出到报告中，反之亦然插入的记录。
[...] |
因此，您已经在其他地方涵盖了“可接受的”差异。
除了165个字节的描述外，每个文件记录还具有一个项目密钥和一个序列号。如果从字面上看，一个项目密钥的描述可能有100,000个（因此，您允许500,000个）。
这些描述不是按顺序排列的，这可能意味着某种程度上序列号不是按顺序排列的？还是您的意思是说描述是按时间顺序排列的，因此某个特定键的序列0000001至序列0000002可能与另一个键的一个或多个描述记录分开？
到目前为止，您没有将“键”（可能不是必需的）和“序列号”留在表中。在序列中，那又是2兆。不超过50％的业务增长，您的解决方案就陷入停滞。好的，您可以将其添加到更多的工作存储中以使其继续运行，但这并不是一个特别聪明的主意。
我不知道我是否是enrico的浪费时间的人之一（如果能成为一个好人，就无法解决问题），但我继续对此事po之以鼻。当我们有了解决问题的第一个想法时，一开始很难接受我们可能没有最好的解决方案。这是我们的解决方案，我们喜欢它。我们将坚持下去。如何分解？只是扑打可能会巩固这个想法，而不是削弱对它的信心。其他一些选择可能会使事情以不同的方式进行。
库纳尔·贾因（Kunal Jain），除非您可以显示原因的更多信息，否则您无需庞大的表即可完成此任务。您有多少记录？百分之十的键具有100,000个描述？您只是在举报吗？您多久执行一次工作？ |
|
| 回到顶部 |
|
|
库纳尔·in那
新的用户
加入时间：2011年5月19日
帖子：59
地点：印度
|
|
|
|
该文件有大约1亿5千万条记录。对于很少的Item-key，大约有8个项目描述。大约1％的项键具有1至9个记录。
我需要报告商品说明的不匹配（&还有多余的（如果存在于任何文件中）。此比较每月进行一次。 |
|
| 回到顶部 |
|
|
库纳尔·in那
新的用户
加入时间：2011年5月19日
帖子：59
地点：印度
|
|
|
|
| 要添加更多内容，此比较是用旧过程的o / p验证新过程的o / p。 |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
好的，对不起库纳尔·in那（Kunal Jain），这是什么？我偶然知道一个紫胶/ lakh，所以我猜是一百万或一千万，但有所作为。
如果您已经有8个紫胶，那么它们在5个紫胶表中的表现如何？而且您还有9紫胶吗？ |
|
| 回到顶部 |
|
|
库纳尔·in那
新的用户
加入时间：2011年5月19日
帖子：59
地点：印度
|
|
|
|
对困惑感到抱歉...
2个VSAM文件拥有大约1.5亿条记录。
只有1％的项目密钥具有5条lacs记录。 |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
好的，所以您的巨型桌子已经装满了。除非您可以绝对确定地说，否则说明的数量将不会超过您已有的500,000（或左右）。
不幸的是，1.5亿中的“只有1％”仍然是150万。因此，这需要大量使用您的桌子，因此您必须在访问桌子方面做得非常好，否则它将像我们所说的那样“像一条没有腿的狗一样奔跑”。
您能解释一下文件结构吗？
您可以回头看看已经问过的问题吗？[/ code] |
|
| 回到顶部 |
|
|
库纳尔·in那
新的用户
加入时间：2011年5月19日
帖子：59
地点：印度
|
|
|
|
1.5亿是所有项目键的总项目描述。
文件大约有1万个项目密钥，只有1％（共10k个）密钥最多包含5个项目描述。这两个文件具有相同的结构
文件结构：
FD输入文件1
记录165
标签记录标准。
01 INPUT1-REC。
05项目关键图片X（17）。
05 ITEM-DESC图片X（148）。 |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
| 好，您提到的序列号在哪里？密钥是如何构造的？它们独特吗？它是什么类型的VSAM文件？ |
|
| 回到顶部 |
|
|
库纳尔·in那
新的用户
加入时间：2011年5月19日
帖子：59
地点：印度
|
|
|
|
项目密钥->
05 ITEM-KEY。
10关键图片x（7）。
10 SEQ pic X（10）。
VSAM文件为KSDS。
对于相同键的项目desc，只是seq继续为每个desc递增，以便区分相同键的desc。
请让我知道是否需要更多信息 |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
到这个话题有点迟了，而且“离题”，但是..
| dbzTHEdinosauer写道： |
有些商店不允许NOSSRANGE。
尽管您提供的帐单可以正常使用（有时我自己使用过），
另一种可能的解决方案
（如果您不必在同一条语句中引用两个表）
是使用一个01，使用两个05，一个重新定义另一个，并且
在表a和表b之间的触发器，带有指向指针短语的集合（01链接项）。
实际上，我同意Bill的看法，并且使用非大表处理。
两个500,000 165个字符的项目表的问题，
您正在尝试加载所有内容。
如我之前所说，
如果要处理500,000个165字符的项目还不够，该怎么办？
由于您需要同时比较两者，
将项目从表A移至工作存储
翻转地址
将项目从表b移动到工作存储区，
做比较。
但是再次
您认为您可以将世界加载到内存中并使用它。
不能总是做到这一点，不如学习如何设计一个完整的过程
而不是尝试在一个程序中解决问题。 |
我想如果规则是SSRANGE，则必须对其进行编译（安装时可以“锁定”选项，这样它们就可以编译，因此您实际上无法更改）。而且我认为不关闭运行时的检查是法律的“精神” :-)
我还是不喜欢SSRANGE。我很容易被说服。
对于“翻转地址”，我建议
| 码： |
01 L-ADDRESS-SWAP-BYTE-1重新定义了gigantic-table-1
05 FILLER PIC X.
|
与其他表相同。
否则，每当您翻转地址时，程序将执行giga-of-gangantic / 4096操作，以使冗余BLL可寻址。对于80mcg，每次翻转将近20,000不必要的BLL设置。您唯一需要的BLL（用于下标/索引）是第一个BLL，设置上面的地址将为您提供。
我希望这与当前要求无关，但是对于以后无法避免使用庞大表的用户而言。 |
|
| 回到顶部 |
|
|
dbzTHEdinosauer
全球主持人
已加入：2006年10月20日
帖子：6967
位置：瓷宝座
|
|
|
|
SSRANGE使动物保持一致。
讨厌浪费时间调试SSRANGE捕获的内容，
当新秀（或实际上是新秀的经验丰富的程序员）时
用他们的代码做愚蠢的事情。
但是，我在生产中不提倡SSRANGE，确实使用了一些资源。
副主题：
我总是使用1个字节的链接区域。然后在该地址上浮动一个链接定义，因此不会输入BLL重新对齐。
就试图解释一个1字节的链接区域而言，在该aderess上浮动另一个链接区域实在是太令人期待了。所以，我没有。
我对此线程的唯一想法，
恩里科（Enrico）早先说过：
为什么在糟糕的设计上浪费好的技术解决方案？ |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
OK，获取SSRANGE点。也许您应该有一个“ SSRANGE盒子”，就像一个“誓言盒子”。每当SSRANGE踢球时，罪魁祸首就得掏10美元。在月底之前将未分配者平均分配。
我的BLL点不是给你的，迪克，我只是有点恐慌，有一天某人实际上会在论坛上进行搜索，这将是他们所需要的主题，然后他们将按原样进行。 ”“怪，好吧，实际上，你到底是怎么回事。我不认为我有很多Cobol技巧，你都不知道:-)
你是对的，恩里科是对的。 |
|
| 回到顶部 |
|
|
比尔·奥博伊尔
CICS主持人
已加入：2008年1月14日
帖子：2504
地点：美国乔治亚州亚特兰大
|
|
|
|
为避免超出数组HIBOUNDS，请在HOUSEKEEPING中预先计算此数组最大值，并在整个代码中将此最大值用作HIBOUNDS。无论是否发生OCCURS，它始终是正确的。
范例-
| 码： |
03 WS-FWORD PIC 9(08) COMP.
03 WS-ARRAY-REC.
05 WS-ARRAY-Entry出现100次
X-WS-AE，X-WS-AE-MAX的索引
PIC X(256).
WS-ARRAY-REC的长度除以WS-ARRAY-Entry的长度(1)
GIVING WS-FWORD.
组 X-WS-AE-MAX TO WS-FWORD.
|
硬编码array-max用于鸟类。
法案 |
|
| 回到顶部 |
|
|
恩里科·索里切蒂
高级主持人
已加入：2007年3月14日
帖子：10715
所在地：意大利
|
|
|
|
请避免使用本地行话或您自己的语言
由于我们需要时间来理解您的问题，因此您可以避免我们理解和翻译您的语言的麻烦
（千万卢比，百灵鸟和朋友）
几乎没有时间锁定主题，看起来它什么都没做，只是在浪费大家的时间  |
|
| 回到顶部 |
|
|
比尔·奥博伊尔
CICS主持人
已加入：2008年1月14日
帖子：2504
地点：美国乔治亚州亚特兰大
|
|
|
|
恩里科
这是否意味着我需要停止使用“ FWORD”？ 
法案 |
|
| 回到顶部 |
|
|
恩里科·索里切蒂
高级主持人
已加入：2007年3月14日
帖子：10715
所在地：意大利
|
|
|
|
Na！
IIRC FWORD长期以来一直是IT专业术语的标准术语
（HWORD，FWORD，DWORD等） |
|
| 回到顶部 |
|
|
赤胜
全球主持人
已加入：2009年10月3日
职位：1788
地点：伊利诺伊州布卢明顿
|
|
|
|
| 恩里科·索里切蒂写道： |
Na！
IIRC FWORD长期以来一直是IT专业术语的标准术语
（HWORD，FWORD，DWORD等） |
我有 决不 听到同事使用“弗洛德”。当然，我不会  |
|
| 回到顶部 |
|
|
尼克·克劳斯顿
全球主持人
加入时间：2007年5月10日
帖子：2455
地点：英国汉普郡
|
|
|
|
| 如果安装了SUPERC或COMPAREX，为什么不运行它呢？ |
|
| 回到顶部 |
|
|
比尔·伍德格
主持人荣誉
加入时间：2011年3月9日
帖子：7311
位置：矩阵内部
|
|
|
|
| 比尔·奥博伊尔写道： |
为避免超出数组HIBOUNDS，请在HOUSEKEEPING中预先计算此数组最大值，并在整个代码中将此最大值用作HIBOUNDS。无论是否发生OCCURS，它始终是正确的。
范例-
| 码： |
03 WS-FWORD PIC 9(08) COMP.
03 WS-ARRAY-REC.
05 WS-ARRAY-Entry出现100次
X-WS-AE，X-WS-AE-MAX的索引
PIC X(256).
WS-ARRAY-REC的长度除以WS-ARRAY-Entry的长度(1)
GIVING WS-FWORD.
组 X-WS-AE-MAX TO WS-FWORD.
|
硬编码array-max用于鸟类。
法案 |
很好
但是，我希望自己也有蛋糕和吃的东西，同时还要有硬编码的最大值（对于鸟类来说，可能是“种子蛋糕”）。
原因是，当有人带着改变表的意图来扩展发生的事情时，他们所做的就是...只要改变array-max ...如果Cobol允许您这样做，或者从OCCURS子句中获取最大值，但不是。现在，有了您的想法Bill，也许我们也可以解决。
| 码： |
03 WS-ARRAY-MAX PIC 9(08) COMP VALUE 100.
03 WS-FWORD PIC 9(08) COMP.
03 WS-ARRAY-REC.
05 WS-ARRAY-Entry出现100次
X-WS-AE，X-WS-AE-MAX的索引
PIC X(256).
WS-ARRAY-REC的长度除以WS-ARRAY-Entry的长度(1)
GIVING WS-FWORD.
如果WS-FWORD不等于WS-ARRAY-MAX
报告并优雅地崩溃
万一
组 X-WS-AE-MAX TO WS-FWORD.
|
我知道这似乎是多余的，但它抓住了应该更改OCCURS的那些时间，但实际上并没有，最大更改了。 |
|
| 回到顶部 |
|
|
库纳尔·in那
新的用户
加入时间：2011年5月19日
帖子：59
地点：印度
|
|
|
|
谢谢大家的建议。
我已经知道了解决方案的途径。
我很高兴收到对我的问题的深入分析和建议。
非常感谢..  |
|
| 回到顶部 |
|
|
|
|
