| View previous topic :: View next topic |
| Author |
Message |
ROBERTLa
Beginner
Joined: 07 Dec 2003
Posts: 8
Topics: 5
|
 Posted: Mon May 24, 2004 8:10 am Post subject: checksum host files from external sources via Cobol |
 |
|
Gents:
We receive nightly sequential-files from external sources (utility companies etc) transferred to us via Connect-Direct, FTP and heaven knows what. These are edited for errors at our site via a Cobol pgm before running in our nightly batch, using simple record-counts in the file header record. But this only detects dropped records.
We'd like the file's sender to include a simple header field with the checksum field for the entire file, to detect bit level data corruption. We'd then enhance our Cobol edit pgm read the whole file - calculating a Checksum to compare to the header from the sender.
1: Our Cobol edit pgm running under os/390 needs to be able to invoke a file-oriented checksum routine somehow. I haven't seen MVS callable checksum routines on the web so far for files or even record-by-record.
2: The MD5 / CRC routines found on the web seem to use a separate file to hold the checksum. We need it as a header inside each seq data-file.
3: Is it even necessary (with todays modern file xfer utils and comms networks) to worry about bit-level corruption ?
Any Ideas
Rob |
|
| Back to top |
|
 |
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12380
Topics: 75
Location: San Jose
|
| Posted: Mon May 24, 2004 8:59 am Post subject: |
|
|
Rob,
I have never come across a checksum routine in cobol. A simple way to calculate a checksum is to add all collating rank values and keeping only the lower 8, 16 or 32 bits of them. But this algorithm, if known, might be misused easily.
SAS has the subroutine dmytecks which will perform the checksum on a file upto 200 characters. In the following example, the final checksum is stored in CALC_CS2.
| Code: |
data _null_;
length string1 string2 $200 checksm1 checksm2 calc_cs1 calc_cs2; */
/* The string received from the DataMyte is longer than 200 */
/* characters, so it is split into two string, STRING1 and */
/* STRING2. However, you must calculate the checksum for the */
/* entire string (STRING1||STRING2). SAS statements reading */
/* in data from DataMyte until EOT is found. */
/* Initialize the first checksum. */
checksm1='00'x;
call dmytecks(string1,ckecksm1,calc_cs1);
checksm2=calc_cs1;
call dmytecks(string2,checksm2,calc_cs2);
run;
|
Hope this helps...
Cheers
Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
Mervyn
Moderator
Joined: 02 Dec 2002
Posts: 415
Topics: 6
Location: Hove, England
|
| Posted: Mon May 24, 2004 4:39 pm Post subject: |
|
|
I may be wrong, but don't Connect:Direct, FTP and heaven knows what already perform checksum validation transparently?
I'd go along with your option 3, and back that up with a normal header and/or trailer record.
_________________
The day you stop learning the dinosaur becomes extinct |
|
| Back to top |
|
|
superk
Advanced
Joined: 19 Dec 2002
Posts: 684
Topics: 5
|
| Posted: Mon May 24, 2004 8:35 pm Post subject: |
|
|
I'm with Mervyn. First of all, consider the impact this type of requirement would have on your trading partner community. There is no way of knowing how these files are produced and on what platforms. Having worked at company that had to produce just such as thing for Insurance claims processing, it was a freakin' nightmare.
Mervyn is right. All of those method of data exchange use sophisticated CRC and error-correction protocols that would make such an event extremely unlikely. |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
