|
View previous topic :: View next topic
|
| Author |
Message |
Arnab.Mukherjee
New User
Joined: 06 Aug 2007
Posts: 5
Location: Stockholm
|
|
|
|
Hi,
I want to copy all the generations to an output dataset. The input files are all of FB but of different lengths. Please help.
Regards,
Arnab |
|
| Back to top |
|
 |
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
You have multiple members of a GDG that have different FB lrecls? Whose idea was that?  |
|
| Back to top |
|
|
Arnab.Mukherjee
New User
Joined: 06 Aug 2007
Posts: 5
Location: Stockholm
|
|
|
|
 ... yes thats bad. But there is an existing program that creates a generation (only one) with the maximum record lengths of the records daily. But if the program executes second time with different input records, it creates another generation and this time taking the maximum of the record lengths to determine the record length of the new generation. Like this, I've different generations with different record lengths.
Now, will this ICEGENER copy them to a single output dataset?
//COPY1 EXEC PGM=ICEGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=.....,DISP=OLD (The input GDG with different record lengths)
//SYSUT2 DD DSN=...... ,DISP=(,CATLG,DELETE),
// DCB=(RECFM=FB,LRECL=37,BLKSIZE=25900),
// SPACE=(CYL,(10,10),RLSE) (The single output dataset)
//SYSIN DD DUMMY
//
Regards,
Arnab |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
I'm nor sure, but I kind of doubt it......
Is this "copy" a one time thing or a regular production "requirement"?
If this is going to be ongoing, VB would work very well.....
I don't thing even DFSORT could read in multiple lrecls of various FB datasets....
On a one time basis, it can be done, but it won't be easy.....
VB is the way to go, if that existing program can be convinced to output VB datasets, the future will be rosy..... |
|
| Back to top |
|
|
Arnab.Mukherjee
New User
Joined: 06 Aug 2007
Posts: 5
Location: Stockholm
|
|
|
|
This does not happen always. Normally, we have only one generation. But, for erronius cases we can have multiple execution of the existing program and that results multiple generations which can be of different record lengths.
Bad luck, I can't change the existing system to output VB. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| You have provided additional information, Frank will have the last word on this, but I do think that each different lrecl file will have to be dealt with individually, let's give it a day and re-attack it with a fresh outlook.... |
|
| Back to top |
|
|
Arnab.Mukherjee
New User
Joined: 06 Aug 2007
Posts: 5
Location: Stockholm
|
|
|
|
| Thank you. Waiting for the solutions. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
If this is going to be ongoing, VB would work very well.....
I don't thing even DFSORT could read in multiple lrecls of various FB datasets.... |
That's correct. For FB, the records lengths must be the same for DFSORT. You would need to pad them all to the same length. You could do that in one ICETOOL step something like this:
| Code: |
//S1 EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN1 DD DSN=... input file1
//IN2 DD DSN=... input file2
...
//OUT DD DSN=... MOD output data set
//TOOLIN DD *
COPY FROM(IN1) TO(OUT) USING(CTL1)
COPY FROM(IN2) TO(OUT) USING(CTL1)
...
//CTL1CNTL DD *
INREC OVERLAY=(c:X)
/*
|
where c is equal to the LRECL of the longest input file. Note that OUT must be a MOD data set. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
If i understand correctly, you have an unknown number of generations and each might have a different lrecl.
You mention that VB is not an option. Is there some business reason why not? Even though you don't specify VB, your data is variable.
Is there some reason that the program cannot be changed to always use the maximum lrecl if for whatever reason VB cannot be used? When you run the copy with the current files, the output is all going to be the max lrecl anyway and if you went ahead and created the files w/max you could save a lot of jumping thru hoops to get to the consolidated max-lrecl file.
While you may have inherited this, i'd suggest that it not be continued. Changing to VB or max lrecl will make this much more maintainable/supportable. Keep in mind (if i understand correctly), each time this file consolidation job is run, it will take some number of custom copy jobs/steps to get the files in shape for the creation of the common file.
Have you thought of how this combiled file might be read back into a program/utility? That too may not be straightforward and it will surely happen at 3a.m. if it does. . .  |
|
| Back to top |
|
|
Arnab.Mukherjee
New User
Joined: 06 Aug 2007
Posts: 5
Location: Stockholm
|
|
|
|
Thanks Frank. But as Dick mentioned, the input file is all the generations and so it is dynamic (I can't know how many input files are there) and the maximum of record lengths among those generations is also not known in advance.
Dick: I don't have the privilage to change anything to the existing program that is producing the FB generations of different record lengths , because some other systems are dependent on those stupid output and they are running fine. And for reading the consolidated file also, is not a problem as finally we are dealing with a single file.
Regards,
Arnab |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Arnab.Mukherjee wrote: |
| Thanks Frank. But as Dick mentioned, the input file is all the generations and so it is dynamic (I can't know how many input files are there) and the maximum of record lengths among those generations is also not known in advance. |
The max rec length is the max for any, not just the input. Max length expected by the input progs.
The number of COPYs (and their DDs) need to be determined, either manually or by a scan of the catalog looking at the count of generations in the GDG (sounds like a REXX question already posted?). |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| I just love shops that are soooo clever that they use dynamic allocation to the point that they have no continuity. |
|
| Back to top |
|
|
|
|
