Page 1 of 1

Cobol program replacement

PostPosted: Tue May 06, 2008 9:05 pm
by mainimpl
Hi,
i would like to replace a cobol program by a more flexible solution. Whenever our group is requested to modify a specific cobol application, it takes between 3 to 6 months to deploy in production. If we do it with JCL, we get a one week turnaround. I don't know if Icetool can do this, i gave it a try with icetool but i need to be set in the right direction and i hope to be able to apply the code to other programs. Here is what the program needs to do:
Read 3 files, the key is in cc, 1 to 20. Merge the files based on the key by appending data at the end of each record. i.e. file#2 (account) is written at the end of file#1(client) and file#3 (document id.) is appened at the end of file#2. The challenge is that file#1 and file#3 have unique keys while file#2 may have multiple keys of the same. Duplicate keys are to be kept.
see sample below: (hope the cut/paste did not missalign the text)

Client file (key is unique)  Total: 180 chars  (20 + 32 + 32 + 32 + 32 + 32)
123456          Name1a  ADDR1a  Addr2a  Addr3a  Addr4a
123457          Name1b  ADDR1b  Addr2b  Addr3b  Addr4b
123458          Name1c  ADDR1c  Addr2c  Addr3c  Addr4c
123459          Name1d  ADDR1d  Addr2d  Addr3d  Addr4d

Account file (key is not unique) Total:  90 chars (20 + 10 + 20 + 20 + 20)
123456          123456A Field1a Field2a Field3a
123456          123456H Field1b Field2b Field3b
123457          123457B Field1c Field2c Field3c
123457          123457H Field1d Field2d Field3d
123457          123457P Field1e Field2e Field3e
123458          123458C Field1f Field2f Field3f
123459          123459C Field1g Field2g Field3g
123459          123459D Field1h Field2h Field3h

Document File (key is unique)    Total 22 chars (20 + 2) Records may be present.
Content: Client#, star, number

123456          *2
123458          *
123459           2

Expected results:

123456          Name1a  ADDR1a  Addr2a  Addr3a  Addr4a  123456A Field1a Field2a Field3a  *2
123456          Name1a  ADDR1a  Addr2a  Addr3a  Addr4a  123456H Field1b Field2b Field3b  *2
123457          Name1b  ADDR1b  Addr2b  Addr3b  Addr4b  123457B Field1c Field2c Field3c
123457          Name1b  ADDR1b  Addr2b  Addr3b  Addr4b  123457H Field1d Field2d Field3d
123457          Name1b  ADDR1b  Addr2b  Addr3b  Addr4b  123457P Field1e Field2e Field3e
123458          Name1c  ADDR1c  Addr2c  Addr3c  Addr4c  123458C Field1f Field2f Field3f  *
123459          Name1d  ADDR1d  Addr2d  Addr3d  Addr4d  123459C Field1g Field2g Field3g   2
123459          Name1d  ADDR1d  Addr2d  Addr3d  Addr4d  123459D Field1h Field2h Field3h   2


For all 3 files, the key is 20 bytes long.
Namexx, Addrxx are 32 chars each, Fieldxx are 20 chars.
The client# and the document# repeats at each occurence of the account#.
The account# information is placed at the end of the matching client record and the document# is
tagged at the very end of the record.
If ICETOOL may be use for this, i would really appreciate you get me started in the right direction. Once i understand the pattern, i will be able to take it from there and apply the logic to other formats.
Thanks.
Alan.

Re: Cobol program replacement

PostPosted: Wed May 07, 2008 2:50 am
by skolusu
Hi mainimpl,

The following DFSORT/ICETOOL JCL will give you the desired results. Make sure to have Disp=MOD for both T1 and T2 temp files

A brief explanation of the job.

1. The first copy operator takes in the 180 byte file as input and adds 2 bytes at the end which would later be used to pad the star and number from your 22 byte file and creates output file T1.

2. The second operator takes in the 22 byte as input and puts the star and number in position 181 and creates output file T1.

3. Since we used DISP=MOD all the records from 180 byte file and 22 byte file are appended and now we splice on the key and a create a single record with star and number at the end of every record for your 180 byte file and create another temp file T2.

4. The next copy operator takes in the 90 byte file as input and adds 182 blanks in pos 90. This is done accomadate the contents from 180 byte file and 22 byte file and creates output file T2.

5. Since we used DISP=MOD all the records are appended and now we splice once again on the key and a create a single record with contents from 180 byte and 22 byte file at the end of every record for your 90 byte file and create the desired output

//STEP0100 EXEC PGM=ICETOOL                                           
//TOOLMSG  DD SYSOUT=*                                               
//DFSMSG   DD SYSOUT=*                                               
//IN1      DD DSN=Your 180 byte lrecl file,DISP=SHR                                       
//IN2      DD DSN=your 22 byte lrecl file,DISP=SHR                                       
//IN3      DD DSN=your 90 byte lrecl file,DISP=SHR                                       
//T1       DD DSN=&&T1,DISP=(MOD,PASS),SPACE=(CYL,(X,Y),RLSE)         
//T2       DD DSN=&&T2,DISP=(MOD,PASS),SPACE=(CYL,(X,Y),RLSE)         
//OUT      DD DSN=Your output file,
//            DISP=(NEW,CATLG,DELETE),
//            UNIT=SYSDA,
//            SPACE=(CYL,(X,Y),RLSE)
//*
//TOOLIN   DD *                                                       
  COPY FROM(IN1) USING(CTL1)                                         
  COPY FROM(IN2) USING(CTL2)                                         
  SPLICE FROM(T1) TO(T2) ON(01,20,CH) -                               
  WITH(181,2) WITHALL KEEPNODUPS USING(CTL3)                         
  COPY FROM(IN3) USING(CTL4)                                         
  SPLICE FROM(T2) TO(OUT) ON(01,20,CH) WITH(01,90) WITHALL USING(CTL5)
/*                                                                   
//CTL1CNTL DD *                                                       
  OUTFIL FNAMES=T1,OVERLAY=(181:2X)                                   
/*                                                                   
//CTL2CNTL DD *                                                       
  OUTFIL FNAMES=T1,BUILD=(1,20,181:21,2)                             
/*                                                                   
//CTL3CNTL DD *                                                       
  OUTFIL FNAMES=T2,BUILD=(1,20,91:1,182)                             
/*                                                                   
//CTL4CNTL DD *                                                       
  OUTFIL FNAMES=T2,BUILD=(1,90,91:182X)                               
/*                                                                   
//CTL5CNTL DD *                                                       
  OUTFIL FNAMES=OUT,                                                 
  BUILD=(91,180,21,70,271,2)                                         
/*


Hope this helps...

Cheers

Kolusu

Re: Cobol program replacement

PostPosted: Wed May 07, 2008 7:10 am
by dick scherrer
Hello mainimpl and welcome to the forums,

Whenever our group is requested to modify a specific cobol application, it takes between 3 to 6 months to deploy in production. If we do it with JCL, we get a one week turnaround.
Seems rather inconsistent that you can add whole new processes (code) in a week and to do the same with some other code in 3-6 months.

The solution skolusu provided is just another program - it is not "jcl". This solution should be documented and promoted the same way cobol code would be promoted. If code with this capability is simply dropped in, in some short amount of time, the system may become quite unstable.

I suggest that 3-6 months is inappropriate to promote already working and tested code.

Re: Cobol program replacement

PostPosted: Wed May 07, 2008 8:20 pm
by Frank Yaeger
The solution skolusu provided is just another program - it is not "jcl".


The solution provided uses DFSORT's ICETOOL - a high quality utility from IBM that has been "tested" by numerous customers in numerous environments for many, many years (ICETOOL has been available since 1991). Given that, I think it's rather misleading to compare DFSORT to a hand-written one-off COBOL program, or imply that the use of DFSORT jobs will somehow lead to instability.

Re: Cobol program replacement

PostPosted: Thu May 08, 2008 4:36 am
by dick scherrer
Hi Frank,

Given that, I think it's rather misleading to compare DFSORT to a hand-written one-off COBOL program, or imply that the use of DFSORT jobs will somehow lead to instability.
There is no question that DFSORT is highly tested. There was no implication intended that using DFSORT would lead to instability.

There was a flat-out statement that short-cutting the turnover standards for code promotion will most likely lead to system instability (this regareless of the "language" used). This has nothing to do with the quality of the DFSORT distributed code. I susect that very few users actually find problems with the DFSORT internal code.

The same is not true of the solutions written in DFSORT/ICETOOL "code". Many, many of the "solutions" offered by posters either won't work at all or will work, but not completely correctly (as you have seen on multiple forums). If people are slipping rather complex solutions into production without having to follow turnover standards (which probably includes user acceptancve testing), i believe there should be concern.

Again, my post had nothing to do with the quality of DFSORT, but rather the questionable management of allowing this type of promotion. I also believe that the standard turnover time is too long, unless that system plans on only releasing application updates twice a year or so. . .

Sorry if i wasn't clear.

d

Re: Cobol program replacement

PostPosted: Thu May 08, 2008 4:45 am
by Frank Yaeger
Many, many of the "solutions" offered by posters either won't work at all or will work, but not completely correctly (as you have seen on multiple forums).


Yes, that's true. But this solution was offered by Kolusu, a DFSORT developer with excellent credentials, so it doesn't fit that category.

Sorry if i wasn't clear.


Ok. I just couldn't let the implications about DFSORT of your post stand as I interpreted them. I'm glad to hear I misunderstood you.

Re: Cobol program replacement

PostPosted: Thu May 08, 2008 7:42 am
by dick scherrer
Hi Frank,

I just couldn't let the implications about DFSORT of your post stand as I interpreted them.
Understood and agreed.

I'm glad to hear I misunderstood you.
Me too :)

d

Re: Cobol program replacement

PostPosted: Fri May 09, 2008 12:35 am
by mainimpl
Thanks to mr SKOLUSU for the suggestions, i was able to apply the same logic to a much bigger record layout and the results perfectly match the output of the cobol program. I am very happy.
Again.. Thank You

Alan.