View previous topic :: View next topic |
Author |
Message |
suma Beginner
Joined: 23 Jan 2006 Posts: 65 Topics: 29
|
Posted: Tue Nov 30, 2010 9:12 am Post subject: Data truncation |
|
|
Hi all,
Currently we have a file which is 60 bytes long, this is the file which is used in many jobs and its length can't be changed.
One of our vendors are sending new set of records file which is 65 bytes long.
As per requirement I should accommodate the 65 bytes long records in 60 bytes file, Please let me know if how to do this without losing any truncated data?
thanks for help.
regards
Suma |
|
Back to top |
|
|
expat Intermediate
Joined: 01 Mar 2007 Posts: 475 Topics: 9 Location: Welsh Wales
|
Posted: Tue Nov 30, 2010 9:44 am Post subject: |
|
|
What you are saying does not make much sense
Either you change all of the programs that read the file or you can not accomodate the extra bytes. _________________ If it's true that we are here to help others,
then what exactly are the others here for ? |
|
Back to top |
|
|
prino Banned
Joined: 01 Feb 2007 Posts: 45 Topics: 5 Location: Oostende
|
Posted: Tue Nov 30, 2010 9:48 am Post subject: |
|
|
Tell your management that they are morons, and ask them to pass on the same message to your external vendor. It will solve all of your problems in one easy swoop, you will loose your job and the vendor will probably cease their dealings with your now ex-employer.
How do you put two UK pints in a single one litre bottle? |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
|
Posted: Tue Nov 30, 2010 11:18 am Post subject: |
|
|
suma,
Check to see if you have any readable numeric fields. if so you can change them to Packed decimal format and reduce the length by half. However you will need to change the other programs which read this data.
Another option is to come up with your own encoding scheme.
Kolusu |
|
Back to top |
|
|
Dibakar Advanced
Joined: 02 Dec 2002 Posts: 700 Topics: 63 Location: USA
|
Posted: Tue Nov 30, 2010 1:09 pm Post subject: |
|
|
Suma,
Look like you don't need extra five bytes.
Just keep a copy of the client file for your boss and trancate it into another file for your application. _________________ Regards,
Diba |
|
Back to top |
|
|
prino Banned
Joined: 01 Feb 2007 Posts: 45 Topics: 5 Location: Oostende
|
Posted: Tue Nov 30, 2010 2:12 pm Post subject: |
|
|
Dibakar wrote: | Look like you don't need extra five bytes.
Just keep a copy of the client file for your boss and trancate it into another file for your application. |
And, dear dimwit, what happens if those five truncated bytes contain essential data?
Anyway, thanks for strengthening the ever growing stream of postings that we can used to warn our employers here against outsourcing to the Indian sub(standard) continent... |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
|
Posted: Tue Nov 30, 2010 3:06 pm Post subject: |
|
|
prino,
This would be the last warning for you. You can voice your concerns else where. This is not the forum for venting out your frustration. Try to respect people first. If you keep repeating the same , you will loose your privileges to post on this board.
Thank you,
Kolusu |
|
Back to top |
|
|
Anuj Dhawan Intermediate
Joined: 19 Jul 2007 Posts: 298 Topics: 7 Location: Mumbai,India
|
Posted: Wed Dec 01, 2010 6:03 am Post subject: Re: Data truncation |
|
|
suma wrote: | Currently we have a file which is 60 bytes long, this is the file which is used in many jobs and its length can't be changed.
One of our vendors are sending new set of records file which is 65 bytes long.
As per requirement I should accommodate the 65 bytes long records in 60 bytes file, Please let me know if how to do this without losing any truncated data? | hmm..is this the first time you have changed the LRECL of some file?
1. Please tell the requesters that you have done the impact-analysis and there is good impact of this change.
2. Have you verified what is there in those extra-5-bytes? If they have increased the length, there has a to be reason and you have all the right to question them back about this.
3. Usually, when you want to aviod the copybook-length expansion - FILLER are used to add the new fields - have you verifed that there are some FILLER in your existing copybook and the "those extra bytes" can actually be accommodate in the existing length itself? _________________ Regards,
Anuj |
|
Back to top |
|
|
Anuj Dhawan Intermediate
Joined: 19 Jul 2007 Posts: 298 Topics: 7 Location: Mumbai,India
|
Posted: Wed Dec 01, 2010 6:48 am Post subject: |
|
|
Prino,
Outsourcing is not bad - if done in a controlled and well designed manner. May be you met only the bad programmers from outsourcing units. However, if you look at this situation from different perspective -- let's say Mr. A owns a Business, he knows he can get the same(okay, similar) work done at pretty low cost from somewhere else and he has enough funds to open a new office at some other place and employ people at a distant location to get his work done... What is next -- Mr. A will do it; without thinking about the local-man-power he has employed earlier.
Ah well, that's what a typical business-man would think - Programmers from different part of the globe have nothing do with this. And as far as IT goes - I'm a believer of "survival of the fittest"...I'm not fit for the market I'll perish...be it India or any other place - does not matter. _________________ Regards,
Anuj |
|
Back to top |
|
|
suma Beginner
Joined: 23 Jan 2006 Posts: 65 Topics: 29
|
Posted: Wed Dec 01, 2010 7:47 am Post subject: |
|
|
There is lot of histroy beyond not asking vendor to send 60bytes. I can explain everything here, but that will not serve my purpose here.
Getting file of 65 bytes long from vendor is one time process. If I wanted to change all the existing program i wouldn't have asked this question in this forum.
I am expecting some expertise answer here, not like Prino who is underestimating sub continent.
Only Kolusu gave some expertise suggestion in this forum, thanks to Kolusu.
thanks everyone for sharing unrelations thoughts.
-
Suma |
|
Back to top |
|
|
papadi Supermod
Joined: 20 Oct 2009 Posts: 594 Topics: 1
|
Posted: Wed Dec 01, 2010 2:43 pm Post subject: |
|
|
Are the new 5 bytes at the end of the record and not needed?
If yes, simply copy the file stripping off those bytes and no other changes would be needed.
If no, and you would like more suggestions, you need to provide more of an explanation of what these new bytes contain and how you need to use them for this one-time process. _________________ All the best,
di |
|
Back to top |
|
|
slade Intermediate
Joined: 07 Feb 2003 Posts: 266 Topics: 1 Location: Edison, NJ USA
|
Posted: Sat Dec 11, 2010 8:03 pm Post subject: |
|
|
What you have to do is analyse the 65 byte data record and determine how it relates to the the original 60 byte data record.
If, as Di suggested, they are at the end of the record construct a SORT job to truncate the record.
If the extra 5 bytes of data are interspersed throughout the record, there are other SORT options that can most likely accomplish the reduction in size to 60 bytes(OUTREC comes to mind).
If the 5 extra bytes are the result of some original field(s) increasing in size, you might have a problem. _________________ Regards, Jack.
"A problem well stated is a problem half solved" -- Charles F. Kettering |
|
Back to top |
|
|
|
|