-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DASDLS: various errors unexpectedly occur in certain situations #393
Comments
I have no idea what you're talking about. |
Closing as PEBKAC (User Error). |
IMO the problem can be easily reproduced in the following way: |
Please see: SUBMITTING PROBLEM REPORTS. You failed to adequately describe/document the problem. We thus do not known (we do not understand) what your complaint is. We do not know (we do not understand) what your problem is. It is rather difficult to fix a problem when one is never told what the problem actually is. dasdls works fine:
|
Even your TITLE does not make any sense! "cchkdasd (64) always issue E 311 with SF" First, there is no Hercules utility called "cchkdasd". Second, your follow-up post mentions dasdls, not "cchkdasd". Third, what the heck does "E 311" mean? Bottom line: your problem report is invalid. It does not make sense, and it does not describe any problem. Therefore there is nothing to be fixed. Nothing is broken. (Except your problem report itself!) |
All the datasets in the example above have one extent only. In cckddasd.c there is the code snippet
I thought E 311 (error 311) would be ok. This message is issued by dasdls -info whenever you have a dataset that has more than one extent on a device cckd device that has shadow files. The reason is that dasdls callls the cckd_sf_init routine a second time inside the chainf3 function. |
There is no problem with dasdls. It appears to be working just fine. |
Okay, I've managed to trigger what I believe you may have been trying to report. I also fully understand that English is likely not your native tongue, and so might have difficulty accurately describing your problem as a result, just as I do sincerely apologize to you for my inability to understand you as a result. I do appreciate the challenge of trying to describe a problem in a language other than your own, and apologize for not initially understanding you. I have done some additional testing with various different dasds and shadow files, and I believe I was able to trigger the problem you were trying to report:
Thank you for reporting this problem (or rather, thank you for TRYING to report this problem!). |
FYI: the problem is not always triggered, even for volumes that have datasets with multiple extents. I did not bother to try and determine the exact condition(s) that cause it to occur, but I believe it is when a dataset has multiple extents and updates to the dataset exist in multiple shadow files. (I think.) The final resolution was to simply fix dasdls's overall design to only open a given dasd image file once instead of multiple times like the way it was currently erroneously doing.
|
Fixed by commit 7124534. Peter? (@peter-sylvester) Can you please confirm that your problem is now fixed? Thanks! |
Yes. Problem is gone. Great. |
Thanks. Closing. |
Using dasdls with shadow files always provokes error 311 in cckddasd.c and cckddasd64.c
The inner loop strcmp for checking duplicate files do not check i != j.
Edit: The originally reported problem was so poorly and inaccurately described and documented that it took a while to eventually figure out what the problem the author was attempting to report actually was. Please see comment 841705811 further below for a description of the actual problem that the author was actually trying to report.
The text was updated successfully, but these errors were encountered: