Comments on: A problem when BDAM files with key are copied by DFSMSdss.

By: ShuroK

ShuroK — Fri, 12 Oct 2012 16:46:19 +0000

Thank you for your suggestions.Instead of asking IBM, I looked into IBM DFSMS manuals. Then I found OS360 BDAM Logic manual on a Web site below.http://bitsavers.trailing-edge.com/pdf/ibm/360/os/bdam/I
did not know such documents are on the Web, did you? They are very
informative for me. But still I can not find any reason of the problem.As for z/OS v1.6, old versions of z/OS are used in Japan commonly. Even OS/390 is still used by some customers of the product.Shuro

By: TomLiotta

TomLiotta — Wed, 10 Oct 2012 00:07:11 +0000

It appears that physical position may indeed be related to the underlying cause; otherwise I'd expect CCHH addresses to match. Are you on a machine type that still supports z/OS v1.6? This might require IBM support, but it could take a long time. There might be no remaining IBMers who haven't retired and who know the workings of BDAM. -- Tom

By: ShuroK

ShuroK — Tue, 09 Oct 2012 20:36:41 +0000

Thank you for your interest. Actually the program is an old program product that was developed around 35 years ago. But hundreds of customers are still using the product. I am doing technical support for the product for many years. Sometimes customers happen to copy those BDAM with key files using DFSMSdss logical processing and encounter the same problem. I was asked to find a reason why the problem happens.The format is F. z/OS of the newest incident is V1.6. The position of a record, that is relative track address TTR, is calculated with own randomize algorithm using key and number of allocated tracks known from VTOC. I am sure the position is not a problem because reading a record using the same randomize logic is OK.I have a news that R0 record of logically copied file contains original CCHH data instead of its actual CCHH data as shown in below result of ‘PRINT DATASET’ of DFSMSdss.-*** TRACK(CCHH) 023F0007 R0 DATA 01B6000E37000000 But I don’t know this is related to the problem.Shuro

By: TomLiotta

TomLiotta — Mon, 08 Oct 2012 10:27:34 +0000

Wow. I haven’t seen anyone using BDAM for well over 30 years. I didn’t think anyone ever did it anymore. (But that could be just because of the work I’ve done, or not done.)

Are these V- or U-format records rather than F-format? Also, are you sure these added records are being written to the correct positions? It would seem likely that one of those items is where the problem is.

What version of z/OS are you running? Is this a question that you are only curious about? Or do you actually need to use DFSMSdss with logical processing? The obvious workaround is to use physical processing.

Tom