I have a requirement in which i need to squeeze the first 9 char bytes from a string into a 4 bytes binary field. I'm not sure if this can be done, but i was asked to look into it. I was wondering if i can acomplish this trhough a SORT step, since i'm sure that i can do it with a COBOL program. Basically, what it needs to be accomplished is to move a HOST username plus a control digit (9 bytes) into a 4 bytes length binary field.
Since the name comes in a string of 20 chars, i know the Username comes after a blank, so I used the parse function to extract it, but the doubt is, can I somehow convert it to number and then that number convert it to binary? Is there another way? I was thinking on using ALTSEQ, but i can't seem to find a way
So far, i extracted the name, but how could i convert it?
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
Oliver,
this sounds suspiciously like a requirement for a soundex algorithm.
is there any intent to convert this new 4 byte binary back to the 20 char name and 9 digit number?
how would/will the new 4 byte binary number be used?
so far you have provided us with the following info:
20 char name field
9 digit number
a little more info, and possibly someone can provide a direction/solution.
do not miss-understand me, I am in awe (at times) at what the DFSORT Team can accomplish,
but I think what you have described so far will be quite a test of their abilities.
this sounds suspiciously like a requirement for a soundex algorithm.
[\quote]
Hello dbzTHEdinosauer:
Thanks for your comments:
Actually it is not a Soundex Algorithm (thanks to a Wiki i learnt about it. That can be done? wow!)
dbzTHEdinosauer wrote:
is there any intent to convert this new 4 byte binary back to the 20 char name and 9 digit number?
No. I just basically need to squeeze a 9 bytes char value into that 4 bytes binary field, basically becouse another process expects the data in that format. I though about converting the char into numbers so I don't loose information in the process.
dbzTHEdinosauer wrote:
how would/will the new 4 byte binary number be used?
The field will be passed, among others that I already have without much problem, to a process that uses it for sorting and summarizations among other operations. Basically, In certain conditions, I need to move this 9 bytes char field to the receiving 4 bytes field, but other times, I move another numeric fields that are correct for the format. I'm in the middle of a plataform migration process, and some data dictionaries were not updated, and others were changed without analyzing the impact of the change, and this new 20 bytes char field was changed without realizing the original PIC 9(9) comp field was used where i need to put it. Anyway,
dbzTHEdinosauer wrote:
so far you have provided us with the following info:
20 char name field
9 digit number
a little more info, and possibly someone can provide a direction/solution.
do not miss-understand me, I am in awe (at times) at what the DFSORT Team can accomplish,
but I think what you have described so far will be quite a test of their abilities.
I think i quite got what you meant. And I usually come to the forum when I can't find an answer by myself, and I know the crew of this forums is amazing when it comes to sort and using it in ways that I simply wouldn't have though about it.
The info I provided is just for the need i have. I have the rest of the job ready, but all I need so far is just to convert that field and then move it. The converting process is what I need.
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
Back in the 'olden' days, when memory and disk were expensive and limited, we would convert the customer name and addresses to a more compact form by dropping the first two bits of each character and squeezing the six remaining bits of each character together.
The best we could do was to reduce every eight characters to six.
You could get another bit out of it if you replaced each letter with a unique 0 - 31 bit pattern, but you can not get a 26 character alphabet to fit into the 16 bit possibilities you think you need.
Back in the 'olden' days, when memory and disk were expensive and limited, we would convert the customer name and addresses to a more compact form by dropping the first two bits of each character and squeezing the six remaining bits of each character together.
The best we could do was to reduce every eight characters to six.
You could get another bit out of it if you replaced each letter with a unique 0 - 31 bit pattern, but you can not get a 26 character alphabet to fit into the 16 bit possibilities you think you need.
Thanks CICS Guy
This request reminds me of my old college days. It looks like a Test Question. Now I realize that this might not be possible since,, since I only have 16 bits as youremembered me. It is very little space for 26 letter alphabet and 10 numbers, so I guess I might neeed to think on a different approach... sighs
That other process is almost a Black box to me. All i know is that they expect an unique valor according to the user code in that field, and it must be on that format. I can't see the source code since I don't have the security priviledges to check the code, All i was asked to do was to leave an interface file and this process will handle the rest. That other process (i was told it was from the Data Secutrity Department) is stored in some protected libraries and I can't even see it trhough changeman or it's libraries. Anyway, I was told that they do some totals based on that field among others, so perhaps I could do a sum fields=none for the 9 bytes char Username file, assign It an unique ID as Dick suggest, and put it on the file. I'll Ask is this could be a valid solution if they don't validate it with any master file and if it works, I'll look into an solution for it
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
if the Data Security boys are unwilling to take you 9 char field and convert it themselves,
you might want to explain to them if you can not have their algorithm,
and can not have a list of unique numbers, your only choice is:
four bytes binary gives you 4,294,967,295 potential unique numbers.
I would store my last used secret number in a one row db2 table or a one record vsam file called
Data.Security.Dept.Secret.Fg.Num,
and start from 0.
and would not waste any more time on this idiocy.
Now I understand your location:
...and would not waste any more time on this idiocy.
Now I understand your location:
You brought a little joy to my day.
Seriously, I don't know what's the big secretism around a simple process, but whatever, It is their shop, I'm Just the humble lowly annalist-programer who should be grateful to work for them.... *sighs*
On a non sarcastic note, I just received word from the people responsible for this "secret process" and I was told that they don't require an historical value, just an unique value per daily file per "user code" field. So That means that if in a given day, i have 1.000.000 records, and if within that bunch of records the user code field is only 20 different values, then I can send them a different value from 1 trhough 20 as an translation of the "user code". I still don't know what they really want to do with that. I hate when the requests are not clear enough and I hate above most things that those requests are constantly changed overnight, but if they have informed me that earlier, it would have saved me a lot of time, effort and stress
dbzTHEdinosauer, Thanks for your suggestion. It seemed like a valid thing to try given my current scenario... (y)
Finally i got to an understanding with the security people and we agreed that we would set an incremental value on that field. The file I create on this process is still subject to more processing ahead, but in this point this value was required and so, i created a sequential number per each 20 bytes char field and then this number was assigned to the 4 bytes binary field. This is the code I used:
Code:
//ICETOOL3 EXEC PGM=ICETOOL
//SYMNAMES DD DSN=%%SYMLIB(KEOASFD1),DISP=SHR
//SYMNOUT DD SYSOUT=*
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//E1DQFILE DD DSN=%%DTS.INPXD05X.XOAJ181F,DISP=SHR
// DD DSN=%%DTS.INPXD05X.XOAJ181G,DISP=SHR
//S1DQHEAD DD DSN=&&F1,DISP=(MOD,PASS),
// DCB=(RECFM=FB,BLKSIZE=0),
// SPACE=(CYL,(100,50),RLSE),UNIT=SYSDA
//S2DQRENU DD DSN=%%DTS.INPXD05X.XOAJ181Z.KEOAJ182,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(150,50),RLSE),
// DCB=(RECFM=FB,BLKSIZE=0,DSORG=PS)
//TOOLIN DD *
*SE CREA UN REGISTRO DE ENCABEZADO PARA CADA TIPO DE GESTOR
COPY FROM(E1DQFILE) TO(S1DQHEAD) USING(CTL1)
*SE COPIA EL FICHERO 1 AL FICHERO 2 Y SE MARCAN LOS DIFERENTES GRUPO
*DE REGISTROS EN FUNCION DEL CODIGO DE GESTOR
COPY FROM(S1DQHEAD) TO(S2DQRENU) USING(CTL2)
//CTL1CNTL DD *
SORT FIELDS=(FD1-COD-GESTOR,A)
OUTFIL FNAMES=S1DQHEAD,REMOVECC,BUILD=(KEOACFD1),
SECTIONS=(FD1-COD-GESTOR,
HEADER3=(3C'$',FD1-COD-GESTOR,655:1C' '))
//CTL2CNTL DD *
INREC IFTHEN=(WHEN=INIT,OVERLAY=(700:SEQNUM,4,ZD)),
IFTHEN=(WHEN=(1,3,CH,EQ,C'$$$'),OVERLAY=(700:SEQNUM,4,BI)),
IFTHEN=(WHEN=(1,3,CH,NE,C'$$$'),
OVERLAY=(710:SEQNUM,4,ZD,
FD1-COD-CRIT1:700,4,ZD,SUB,710,4,ZD,BI,LENGTH=4),
HIT=NEXT),
IFTHEN=(WHEN=ANY,BUILD=(KEOACFD1),HIT=NEXT),
IFTHEN=(WHEN=NONE,BUILD=(KEOACFD1))
SORT FIELDS=COPY
OUTFIL INCLUDE=(1,3,CH,NE,C'$$$'),BUILD=(KEOACFD1),FNAMES=S2DQRENU
I though on using group operations to assing the unique value to each Field, but the current PTF on that shop wouldn't let me, so I used a code that Skolusu showed in another request and I think I've got it right. The first tests shows me the results I want. I'm writing again just to know if theres is a more efficient way to do what I did is it allright as it is. I take in consideration that the input files will be quite large, around 10.000.000 records per file
I guess the solution was simpler than I originally though, but the problem was the way the request was made. Thanks again for you support and suggestions everyone
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
ojdiaz wrote:
I though on using group operations to assing the unique value to each Field, but the current PTF on that shop wouldn't let me, so I used a code that Skolusu showed in another request and I think I've got it right. The first tests shows me the results I want. I'm writing again just to know if theres is a more efficient way to do what I did is it allright as it is. I take in consideration that the input files will be quite large, around 10.000.000 records per file
I guess the solution was simpler than I originally though, but the problem was the way the request was made. Thanks again for you support and suggestions everyone
Oliver
ojdiaz,
You don't really need two passes of data to get the results. if your intention is to just sequence the records by group then it is very easy. It can be done in a single pass like shown below
You brought a little joy to my day.
