I am trying to solve a problem using DFSORT and wondering if it is even possible. I am able to achieve this using a REXX program, however, due to the volume of data, wondering if DFSORT could do it faster.
There are two columns containing TAPE volser for a dataset, which can extend on multiple tape volumes, but not in any particular order. So I need to find the head, tail and basically the entire chain. All I know is that head of any chain can only exist in first column with the next volume in the adjacent column.
Thanks Joerg and sergeyken for the inputs. After having dig through the DFSORT manuals for possible solutions, I too felt the same (and learnt a lof of new things along the way), but obviously couldn't get to a solution (hence this post). Can you suggest any possible approaches you would take to solve it, if it MUST BE done using DFSORT.
And yes, the list of volumes in this case is quite high, roughly 400k on just one system.
Yes, the sample data I showed up was not sorted. I just made it up to bring forward the point that it is not necessary that A0001 may link to A0002 for example.
What you have presented above is correct.
I think you are right about the technical limitation of upto 255 volumes, I would have to look it up. But in this scenario, based on my analysis using REXX, the maximum depth of the tapes I found was about 10. I am not really sure if it would be a good idea to assume that as a limit (or maybe a little more, say 15), as long as the solution is dynamic and can be adapted for higher limit in future, I would want to learn about it.
The major trick is: how to use the same JOIN group for any number of join steps? Otherwise the total number of SORT control statements would exceed the size of input data
********************************* TOP OF DATA ******************
A00001 A00002 A00003 A00004
B00001 B00002 B00003
C00001 C00002
D00001 D00002 D00003 D00004 D00005
******************************** BOTTOM OF DATA ****************
Joined: 15 Aug 2015 Posts: 1337 Location: Bamberg, Germany
The ICETOOL solution looks really nice, but wouldn't it be quite a bit of a SORT excess? Well, the other solution would have the opposite of IFTHEN excesses for what I have tried. I don't know if it's worth to be shared yet.
The ICETOOL solution looks really nice, but wouldn't it be quite a bit of a SORT excess? Well, the other solution would have the opposite of IFTHEN excesses for what I have tried. I don't know if it's worth to be shared yet.
I tried some IFTHEN attempts, but the size of the required code is growing exponentially when the length of allowed chain increases.
If you have an acceptable solution, please share it with us.
Joined: 15 Aug 2015 Posts: 1337 Location: Bamberg, Germany
The bottleneck here is that the input must be in correct order for what I have attempted. I would like to read some comments if I am on the right path or not. It's just what came into my mind solving the requirement.
The bottleneck here is that the input must be in correct order for what I have attempted. I would like to read some comments if I am on the right path or not.
In general case, when volume numbers are assigned randomly, I do not see a way to pre-arrange the lines in required order...
The rest of logic seems to work correctly. But the very basic operation - pre-arrangement of input lines - has been done manually, with no visible automation method? I believe so.
Joined: 15 Aug 2015 Posts: 1337 Location: Bamberg, Germany
I have not yet looked deeper into pre-sorting stuff before our both approaches come into place. Maybe you have an idea that can be deployed? I am afraid to not have a good solution at the moment for that (possible) issue.
I have not yet looked deeper into pre-sorting stuff before our both approaches come into place. Maybe you have an idea that can be deployed? I am afraid to not have a good solution at the moment for that (possible) issue.
Your approach works only when source lines are arranged in the order of their "chaining", which is Issue #1.
When this is done somehow, the Issue #2 is: combine multiple sequential lines into one single line, for each group of lines making a single chain.
Issue #2 can be resolved in one single pass, as you have done in your example.
Issue #1 cannot be resolved in one single pass, even theoretically. That's why in my approach multiple file scans have been used.
The ICETOOL solution looks really nice, but wouldn't it be quite a bit of a SORT excess?
Just because of curiosity, I tried to run the ICETOOL version with about 5000 of input lines (as many as I was not lazy to create).
The total job CPU time was 0.35 sec. (with 10 repeated JOIN attempt).
JOIN1 extends all needed chains from 2 to 3 names.
JOIN10 extends all needed chains from 11 to 12 names.
