Skip to main content

1-JUL-1993: Deutsche Bundespost, Zip Codes, USEQREAD

Author: ulrichmerkel@web.de (ulrich-merkel)

20 Years ago, the German Mail introduced the 5 digit ZIP codes and all applications have to replace the former 4digit one (plus a prefix "W-" or "O-" for the former western and eastern part of germany) with the new 5digit values (sounds like the y2k, doesn't it). And there was a lot PR-actions like http://www.youtube.com/watch?v=S9y9H0EB4jE Conversion was a complicate matter because each city had a single zip-code before, now they used a finer granularity and for big cities some long streets have up to 4 different zip codes. So it took a major implementation to code some automatic conversion which may include even the house-number in a street. So all houses on the left side may have a different code than the right side houses. For the actual situation have a look at: http://www.dastelefonbuch.de/Postleitzahlen.html All these data were provided in book form sent to all households, and you could request a CD-ROM. On that CD-ROM, there was a single multi-redord-format file with a size which was more than some harddisks (my had 80 MB). See: http://www.koordinaten.de/informationen/plz_geschichte/ for more details. So a lot of german uniface customers have to process that monster some way. But uniface does not provide (up to now) a feature to process read-only media line by line. The usual way in Uniface drivers is to have a read/write access (so we get errors on read-only media like CD-ROM) and in TXT/SEQ driver, all data are loaded at once which causes a lot of abouts and a lousy performance. Thanks to the 3GL interface, I could solve the problem with just a couple of lines C-code (which is still living as USEQREAD) so we get a brilliant performance no matter how long the file is. Even now, the uniface product does not have support for line-by-line processing of sequential files. Some customers circumvent this loading the sequential file into a database to benefit from stepped hitlists / discard mechanism. But this is a lot of work.

1-JUL-1993: Deutsche Bundespost, Zip Codes, USEQREAD

Author: ulrichmerkel@web.de (ulrich-merkel)

20 Years ago, the German Mail introduced the 5 digit ZIP codes and all applications have to replace the former 4digit one (plus a prefix "W-" or "O-" for the former western and eastern part of germany) with the new 5digit values (sounds like the y2k, doesn't it). And there was a lot PR-actions like http://www.youtube.com/watch?v=S9y9H0EB4jE Conversion was a complicate matter because each city had a single zip-code before, now they used a finer granularity and for big cities some long streets have up to 4 different zip codes. So it took a major implementation to code some automatic conversion which may include even the house-number in a street. So all houses on the left side may have a different code than the right side houses. For the actual situation have a look at: http://www.dastelefonbuch.de/Postleitzahlen.html All these data were provided in book form sent to all households, and you could request a CD-ROM. On that CD-ROM, there was a single multi-redord-format file with a size which was more than some harddisks (my had 80 MB). See: http://www.koordinaten.de/informationen/plz_geschichte/ for more details. So a lot of german uniface customers have to process that monster some way. But uniface does not provide (up to now) a feature to process read-only media line by line. The usual way in Uniface drivers is to have a read/write access (so we get errors on read-only media like CD-ROM) and in TXT/SEQ driver, all data are loaded at once which causes a lot of abouts and a lousy performance. Thanks to the 3GL interface, I could solve the problem with just a couple of lines C-code (which is still living as USEQREAD) so we get a brilliant performance no matter how long the file is. Even now, the uniface product does not have support for line-by-line processing of sequential files. Some customers circumvent this loading the sequential file into a database to benefit from stepped hitlists / discard mechanism. But this is a lot of work.

For those interested in software archaeology: the (more or less) basic codeline: /* **************************** Global Variables */ char SO[8001]; /* Stringbuffer 8K */ char nam_fpi[_MAX_PATH]; FILE *fpi; long rec_cnt; XEXPORT(long) useq_open(void) { UGETREGS(30,nam_fpi,sizeof(nam_fpi)-1); /* Input File */ if (nam_fpi[0] == 0) { UPUTREGS(30,"USEQ_E0001 Input file has to be specified"); return(-11); }; if ((fpi = fopen(nam_fpi,"rt")) == NULL) { UPUTREGS(30,"USEQ_E0002 can't open input file"); rec_cnt = -11; return(-2); } rec_cnt = 0; return(rec_cnt); } XEXPORT(long) useq_close(void) { if (fclose(fpi) == EOF) { UPUTREGS(30,"USEQ_E0003 can't close input file"); return(-5); }; rec_cnt = -2; return(0); } XEXPORT(long) useq_next(void) { /* copies record to $30*/ char *p; if (fgets(SO,sizeof(SO)-1,fpi) == NULL) /* read a record */ return(-3); for(p = SO;*p != '';p++) if (*p=='\\n') *p = ''; UPUTREGS(30,SO); return(++rec_cnt); }


Author: ulrich-merkel (ulrichmerkel@web.de)
Terms & ConditionsAccessibility statement