As simple as it might seem i neveer needed to that until now.
I Need to change a critical copy at my shop and extend it's length to add new fields that will be used by some applications in the first stance and maybe others in the future. Tha's why we'll extend it from 300 to 500 bytes. The problem is that there is a lot of software compiled with that copy and I was told that they won't change it at this time because of time or other issues. Therefore my idea.
If I Can read the record length in a JCL Batch Job of an input FB file, and determine if it is 300 bytes, I could easily alter that file to make it 500 bytes long and use it on my processess without much problem and the minimum impact on their apps until they need to recompile their processess when they'll have to adapt to out jobs
I though on using listcat, but I'm not sure how to extract that info.
I'm sorry if this is a silly question, but well, it would save me a lot of time since . Any suggestions?
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Input files in JCL are usually cataloged, so they do not have LRECL specified. Unless you can find the source code for the program being executed, determine from the source code the expected record length for the file, and proceed from there, you cannot know the LRECL. What you are wanting to do can be done but not easily -- it would probably be less effort to go ahead and change all programs that use the file to use the new record length.
Input files in JCL are usually cataloged, so they do not have LRECL specified. Unless you can find the source code for the program being executed, determine from the source code the expected record length for the file, and proceed from there, you cannot know the LRECL. What you are wanting to do can be done but not easily -- it would probably be less effort to go ahead and change all programs that use the file to use the new record length.
Indeed the files are catalogued. I was hopping that, since writing an "S" next to a file, it gives me all the info associated with it, record length included, i could do what i wanted.
We wanted to minimize the resistance from the other apps to change their sofware because of a need of our application in which they are affected and would be forced to change a huge amount of JCLs and Cobol Programs. What we wanted was a "way" to access the catalog and retrieve this data
That way, I would be able to determine if a file is being written with the new or old copy, and i could take the proper measures. I need to do this, beucase I recive a "file of files", an 80bytes fixed length file with the name of many files which will be processed, and they are the ones affected by this change.
Anyway, is there no way to get this information in a Batch JCL?
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
From what I can see here, you want to change the file for ONE program to append values after the current 300 byte point.
Would it not be easier to run the program and create the new file, and then run a sort step to create the standard 300 byte file. That way you have the two files, one of 300 bytes that can be used as usual, and the new file of 500 bytes that can be used by the application(s) that have been changed or designed to accept this file.
Of course, if the changes occur before the 300 byte point then you need to change everything.
Thanks for the links superk. The second one was right on what i needed.
I'd like to clarify thhough, what is what I'm intending to do.
We have a process, in which we process accounting info from all the applications in the shop. This process works in the following way:
Each application generates a 300 bytes length file with their movements. They add the "file name" to another file. As for the file format, we suppliead each application with a General purpose copy (Lets say, copy A) of 300 bytes length.
We then, process this "File of names" file to read each data file and add it to our internal accounting process. Our process is ready to process each 300 bytes file. The problem is that in the last census, there are over 2000 programs that use that copy and well, the cost of changing all that software is way too expensive.
We need to change that copy struct to add "new" fields at the end of it. What we though was:
Well, let's let them use the old copy and the ones that need to use the new fields use the new one when they recompile their programs. That way, once their program compiles they'll change their jobs accordingly and generate it with the new 500 bytes lenght format and the othes in the old 300 bytes length format.
Whe we wanted to do in our process was read each file in the "file of files", and if it was create with a length of 300 bytes, change it to 500 bytes, using a sort, maybe, and the ones of 500 bytes, well, we'll just let them be. That way the others applications won't be affected by the change in the first instance, and we can go on with our requirement on our side. What do you think of this approach? I hope it was clear enough.
Joined: 06 Nov 2008 Posts: 46 Location: Manila, Philippines
Hi OJ,
I agree with expat.
I believe it's easier to just create the 500-byte file, and for the processes that need the 300-byte file, just use sort to extract the first 300 bytes of the 500-byte file.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
When the file is created, you might consider creating the data in both lengths with different dataset names. Once the last of the "old" programs have been converted to the new format, only 1 file would be needed.
The "old" stuff could use the existing dsn (to minimize changes) and the neew/chaged processes (needing to be changed anyway) would use the new dsn.
