RANDOM函数生成随机数

dcshnier · 发表：2012年4月27日，星期五7:50 pm

有人可以确认我以正确的方式使用了COBOL FUNCTION RANDOM（生成随机数）。
对于特殊测试，我需要复制生产文件，并用看起来真实的假数字替换9位数字的帐号。我的第一种方法是使用FUNCTION RANDOM和“ argument”作为启动项“ 种子”。（根据文档，我只“种”了一次种子）。种子植入后，对于每个输入记录，我随后使用FUNCTION RANDOM（不带参数），目的是将生成的结果用作我的替换帐号。但是，我的第一次尝试生成了不切实际的外观数字，例如“ 000000001”，“ 000000033”等。我希望在没有所有前导零的情况下，外观看起来更逼真。
然后，我在互联网上偶然发现了一个示例，在该示例中，他们用“ 42”倍加+1来操纵FUNCTION RANDOM结果。（我不知道为什么是“ 42”，为什么是+1）。但是，我尝试做类似的操作实验，经过反复试验，我遇到了一个公式，该公式生成逼真的随机数。下面的示例需要将结果乘以“ 333333333”，然后再加回当前输入记录中的原始帐户号。这些操纵数字纯粹是通过反复试验得出的。下面，我将介绍我的工作解决方案，但我不知道为什么我的方法能产生理想的结果。所以我问论坛读者，这种“操纵”方式是否是使用功能随机性的真正规定方式。这是我的工作示例（此示例各部分中使用的伪代码）

05输入-RCD-CNT图9（05）。
05 WS-ORIGINAL-ACCT-NBR图片9（09）。
05 WS-FAKE-ACCT-NBR图片9（09）。
05 WS-SEED图片9（09）

读取输入记录
将+1添加到INPUT-RCD-CNT

如果INPUT-RCD-COUNT = 1 **
将WS-ORIGINAL-ACCT-NBR移至WS-SEED
计算WS-FAKE-ACCT-NBR =
功能随机数（WS-SEED）
万一。

计算WS-FAKE-ACCT-NBR =
（功能随机数* 333333333）+ WS-ORIGINAL-ACCT-NBR。

菲尔比（Phrzby Phil） · 发表：2012年4月27日，星期五8:03 pm

为什么您清理过的帐户＃看起来很真实？

比尔·奥博伊尔

如果这些是信用卡号，为什么不使用PCI标准并用私钥加密呢？然后，您可以根据需要使用相同的密钥对其进行解密。

用随机数伪装后如何解密？

dcshnier · 发表：2012年4月27日，星期五8:10 pm

这是一个有效的问题。
一个简单的答案是，我面临着随后的编辑例程，这些例程会开出看起来不切实际的帐号，例如那些带有过多前导零的帐号等。
但是，即使我没有那些担心的编辑例程，原则上（我拼写正确吗？）也可以期望，即使是伪随机数生成器，其生成的数字也会随机地跨越允许的范围，而不是束手无策我第一次得到。

菲尔比（Phrzby Phil） · 发表：2012年4月27日，星期五8:14 pm

您想要“原理”。

现在，也许您可以回答我的问题：为什么清理过的帐户＃看起来很真实？

也就是说，尽管在学术上有趣的是random＃问题，但是在您的测试中什么要求消毒过的数字“看起来”（即人眼？）“真实”？

比尔·奥博伊尔 · 发表：2012年4月27日，星期五8:18 pm

如果您要使用这些伪装的号码来构建文件，并且该文件要不在家了，那么接收者如何在收到文件后对其进行伪装？

您可以加密DSN本身，保持数字不变，然后收件人可以解密DSN，而不会产生任何后果。

这是惯例。

dcshnier

首先回答Phil：谢谢您的拼写更正。
我的第一个回答有拼写错误，它回答了您有关数字为何必须逼真的问题。答案是：
“我面临着随后的编辑程序，这些程序会淘汰看起来不切实际的帐号，例如那些带有过多前导零的帐号等。”

回答比尔·奥博伊尔：加密是个好主意。
但是，这样做的目的是不呈现正在外出运送的文件。只是生成一个看起来逼真的测试文件，我们可以通过现有程序按原样在测试主机上运行该文件，而无需事先解密。这里的大多数开发人员没有安全检查权限，无法查看真实帐号。因此，我们将获得具有访问权限的人员，通过运行此COBOL例程为我们创建测试文件。我确定还有其他方法（例如，毫秒，微秒等）
但是暂时我想坚持使用COBOL FUNCTION RANDOM来尝试“尽其所能挤牛奶”。如果这是一个真正有价值的功能，那么必须有一种方法可以使用它来产生“散布”的随机数。也许是偶然，我偶然发现了实现这一目标的方法。

菲尔比（Phrzby Phil） · 发表：2012年4月27日，星期五8:31 pm

哦-踢出去=拒绝。错过了。

dbzTHEdinosauer

我不会解决安全问题。

在您的应用程序（生产）中，您有一个例程来生成一个新的帐号，是/否。

为什么不种子那个常规
并生成帐号通过考试!

我可以想到校验位例程，这样会否定您随机例程的工作。

我的建议是放弃它，特别是如果真实帐号不能是随机的

将随机生成的数字乘以333333333，只会强制该基数大于333333333
添加旧帐号可能会导致重复。
333333333是常数乘以变量（随机数）
添加旧帐号与添加变量相同。
2个变量的总和很容易等于2个不同变量的总和。

现在，机会是999,999,999 / 2中的1，但这不是a子。

罗伯特·桑普

我认为您错过了手册中的语句，该语句指示RANDOM返回一个介于0和1之间的值。我的代码：

dcshnier · 发表：2012年4月27日，星期五10:26 pm

谢谢罗伯特！
我实际上发现了关于结果在0到1之间的注释（这意味着它返回一个很长的十进制数字）。但是由于有些其他示例，我读到结果必须是一个INTEGER，因此我还是对此有所遗忘（或掩饰了），此外，其他编码示例（均未使用PIC V9（09）纯十进制格式）。但是，您的示例和显示的结果证明我是错误的。
重要的是，我必须将结果乘以1,000,000,000才能将其恢复为9位整数。这也许就是为什么我早期的结果是渲染带有过多前导零的数字。这也解释了我在互联网上偶然发现的示例，其中他们将结果乘以一个无法解释的数字。
因此，总而言之，使用RANDOM的关键是必须将接收工作存储字段定义为纯十进制-位数等于所需的INTEGER数字位数。并且，您必须将接收到的结果乘以（1nnn ...），其中“ nnn ...”是一个零字符串，等于最终INTEGER结果的所需位数。

为了解决其他人提出的安全问题，这些名称也以一种绝对难以辨认，不可逆转的方式被随机打乱。并且与帐号的功能随机性一起，将产生比仅对帐号的一部分进行消毒（并保留原始名称完整）的许多其他文件更好的清理文件。话虽如此，但已寻求该方法的适当权限。
为了回答任何人担心（偶然）生成不想要的重复项，正在测试的应用程序的性质以及这些文件的内容，使得如果生成重复项，后果将是微不足道的。

再次感谢罗伯特！

dbzTHEdinosauer · 发表：2012年4月27日，星期五10:44 pm

SV9（09）补偿字段与S9（09）补偿字段占用相同的空间。
无需将随机生成的数字相乘即可删除小数。

dcshnier

嗨迪克
除非我做错了事，否则我进行各种尝试来获取PIC S9（09）COMP字段以呈现所有数字而不求助于大数乘法的尝试都是失败的。（它显示为全零）。
但是，即使我可以使用它，最终输出文件仍然需要以PIC 9（09）和PIC 9（09）COMP-3格式生成这些帐号。因此，我仍然必须将PIC S9（09 COMP字段）移到那些最后的字段（即执行该额外步骤）。

无论如何，我可能最终都会保留我在上一个响应中阐明的解决方案；因为我在这里忙于许多并发任务。

迪克·谢勒

节拍无聊。。。

d

比尔·奥博伊尔

如果您的编译器不支持COMP-5（本机二进制），则请确保使用编译选项TRUNC（BIN）避免高阶截断。

否则，请使用COMP-5，而不是COMP，因为COMP-5不会出现截断，并且COMP-5会忽略TRUNC选项。

无符号是更好的选择，因为有符号的二进制全字最大为2147483647（2 ** 31）-1（X'7XXXXXXX'），而无符号的二进制全字最大为4294967295（2 ** 32） -1（X'FFFFFFFF'）。

COMP-5与OS / 390 COBOL 2.2.1一起引入。

菲尔比（Phrzby Phil）

为了进行测试，您是否可以禁用特殊的“看起来像acct＃”检查？

dcshnier

嗨菲尔
任何变通办法都是可能的。但是暂时我们希望测试尽可能使用现有的程序代码。

但是，现在所有这些都没有意义。罗伯特·萨普（Robert Sample）的回答揭示了我早期方法的缺陷。并对此进行调整之后，RANDOM函数现在可以产生实数，而无需我诉诸于先前使用的操纵范围。

比尔·伍德格 · 发表：2012年4月28日星期六12:17 am

dcshnier · 发表：2012年4月28日星期六12:36 am

谢谢Bill的回应。

我应该提到，即使Robert Sample的示例在他的解决方案中使用了一个COMP（二进制）字段（PIC V9（9）COMP），我还是已经成功地将它作为非COMP字段进行了测试-PIC V9（9）。因此，我不确定我的方法会如何改变整体评分。关于他的调整的要点是使用十进制字段（非INTEGER）字段。

关于不切实际的数字被排除在外的问题确实发生在流程的早期，并且并没有在所有地方将它们排除在外。如果我留下那印象，我深表歉意。我的观点是，使用我较早的（有缺陷的）使用RANDOM函数的方法（在Robert Sample纠正我之前），我生成的数字中有90％是不现实的，因此将被踢出去。此拒绝数量是不可接受的。现在，我的RANDOM函数正常工作了（尽管我仍在乘以1,000,000,000），实际上所有的数字都是现实的，将被踢出去的数量现在已经不重要了。如果时间允许，我将继续摆弄您的建议，以消除繁琐的需求。虽然，我确实记得昨天我在谷歌上搜索时，但人们在互联网上发布的两个假定的工作示例中至少有两个都在使结果成倍增加。现在我知道为什么了。

罗伯特·桑普

从手册的措词方式来看，只要结果变量是数字，它就可以是DISPLAY，COMP，COMP-3，没有问题。我不认为浮点数（COMP-1或COMP-2）会起作用。

比尔·伍德格 · 发表：2012年4月28日星期六1:33 am

可能是我，我正在快速阅读。

请这样做，而不是乘以1,000,000,000。

01功能随机结果PIC V9（9）。
01在其他地方使用了大随机数，重新定义了函数结果的小随机数PIC 9（9）。

dcshnier · 发表：2012年4月28日星期六1:46 am

谢谢比尔
在我正在做的许多其他事情之间，我确实意识到您和其他人打算雇用一个REDEFINE（我没有这样做）。
但是我终于开始这样做了，它成功了！
因此，最终的工作解决方案是：

05 WS-INPUT-RCD-CNT图9（05）。
05 WS-ORIGINAL-NBR图片9（09）。
05 WS-FAKE-NBR-DECIMAL PIC V9（09）。
05 WS-FAKE-NBR-非十进制定义
WS-FAKE-NBR-DECIMAL PIC 9（09）。

读取输入记录
将+1添加到WS-INPUT-RCD-CNT
将I-ORIGINAL-NBR移至WS-ORIGINAL-NBR

如果WS-INPUT-RCD-CNT = 1
计算WS-FAKE-NBR-DECIMAL
=功能随机（WS-ORIGINAL-NBR）
万一。

计算WS-FAKE-NBR-DECIMAL
=功能随机。

将WS-FAKE-NBR-非小数位数移动到OUTPUT-FAKE-NBR。

比尔·奥博伊尔

比尔说

比尔·伍德格 · 发表：2012年4月28日星期六5:05 am

抱歉，有点混淆。子例程可能会与TRUNC（BIN）一起使用，如果不是BIN，它将不会使用子例程来完全执行双字操作，并且我还没有检查这是否是BIN使用子例程的时间。

由于需要将全字转换为双字，然后进行数学运算，然后再转换回全字，因此9位数字在处理10-17位数字时要重一些。

10-17位数字即可完成数学运算，无需转换。因此，来自Cobol的10-17位二进制算术将比9位快得多。 1-4最快，10-17秒，9第三，18第四。

如果使用9位数字，则无论如何都要避免数学:-)

我曾经“调整”一些下标，有效地保留了8到9位数字的地址。没有检查，如果我可以在某个地方找到旧的编译器，也许我会在某个时候做。

我从程序中挤出了所有东西，一个“工具”被“发现”，然后在所有部门中使用。对于我们的小型系统，大约需要3-5秒的CPU，而对于较大的系统，大约需要10-30秒。因此，该调整适用于那些不想承认使用它的好处的人，因为在“促销”过程的最后还有三分钟的时间。

无论系统大小如何，我都可以将其降低到一秒钟以内（主要是通过不同的方式进行操作）。我计算出这将节省大量时间。我发送了新文档（SCRIPT / GML / DCF，像手册一样），并强调了将JCL更改为一个CPU秒的时间限制，明确指出了唯一超出此限制的方法是它永远循环。

一个人跑了322。他自言自语：“我非常重要，我的系统非常重要，这花了30秒钟，我需要更改它”。午后，我注意到一个作业以熟悉的程序名称运行（该程序名为OCCULT，因为我们项目组中的常规例程必须启动OC，而我已经使用了OCTOPUS），并且为此花了大量的CPU。他们一直不断向上运动并重新运行，直到他踩到1440并出去吃午饭了:-)

循环的原因？它可以处理Cobol和Assembler程序。由于汇编程序可能比Cobol大得多，所以我有一个限制。在进行更改之前，我曾问过所有人：“您有任何大型汇编程序吗？”这些人说：“哦，不，我们有一些汇编程序，但是它们很小。”

“小型”程序之一是分配大量的存储。实际上，它并不是真正的程序，它只是分配大量存储空间的一种手段。当我问“真的很大”时，他们想到的是代码行:-)我的程序正在循环，永远都在寻找相同的存储块，但从来没有全部存储，因此找不到加载模块中的下一个程序。

当然，当我要求所有人对新版本进行“系统测试”时，那些懒惰的懒惰者只是选择了他们的系统之一，而不必费心在所有系统上运行它。如此重要很美妙，不是:-)

当时我想，“好吧，不值得将8更改为9，它永远不会节省今天浪费的CPU时间”。

我真的有可能减慢了进行更改的速度:-)