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

30 pts.
Tags:
DFSM
z/OS
I have a problem with my BDAM files with key when the files are copied using DFSMSdss of z/OS. If the files are copied using physical processing, everything is OK. If the files are copied using logical processing, reading existing records is OK, but writing a new record into the copied files fails with BDAM Exception Code Bit 2 ON, that means space not found. The original files are filled with dummy records of all law values in the place where no record has been written. The copied files look same. Does anyone know the reason why a new record can not be added?

Software/Hardware used:
DFSMSdss

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • ShuroK
    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
    30 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • ShuroK
    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
    30 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following