What is the field delimiter for Hash files?
Moderators: chulett, rschirm, roy
What is the field delimiter for Hash files?
char(251) or @VM or ???[size=9][/size][/b]
A hash file record is one long string. Each field is separated by @FM or @AM which is a char(254) which is also known as a field mark or an attribute mark. Fields in Universe are also called attributes. Records are sometimes called items.
Each field can hold an array or what are called multivalues. Each multivalue is separated by @VM or char(253). Each multivalue can be an array or what is called a subvalue. Each subvalue it separated by a @SVM which is a char(252).
Each hash key can have multiple key fields which are separated by @TM which is a char(251).
Each field can hold an array or what are called multivalues. Each multivalue is separated by @VM or char(253). Each multivalue can be an array or what is called a subvalue. Each subvalue it separated by a @SVM which is a char(252).
Each hash key can have multiple key fields which are separated by @TM which is a char(251).
Mamu Kim
Just to clarify since the original question had both styles in it and to add to Kim's explaination, syntactially you can use either the pre-definined variables such as @FM or a fucntion like char(254) in your DataStage code syntax. Both work fine, but as a best practices method I think the system variables work best, since seeing @FM or @VM incurrs the thought of 'field mark' or 'value mark' instantly and seeing char(254) in code might make you have to think hard to remember what it is or make you consult your good friend Mr. Ascii Chart.
Byron Paul
WARNING: DO NOT OPERATE DATASTAGE WITHOUT ADULT SUPERVISION.
"Strange things are afoot in the reject links" - from Bill & Ted's DataStage Adventure
WARNING: DO NOT OPERATE DATASTAGE WITHOUT ADULT SUPERVISION.
"Strange things are afoot in the reject links" - from Bill & Ted's DataStage Adventure
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
None of the previous posts is completely correct, as the answer depends on whether you're referring to the internal storage model (in which case the best answer is "you don't need to know") or the structure of the record after you've read it (using a READ statement or one of its variants) and also, in this case, on whether the metadata supports multi-valued fields.
After you've read a record from a hashed file without multi-valued fields, what you have is a string (technically a "dynamic array") containing all of the non-key fields separated from each other by field marks. Field marks are reserved characters, accessible via the system variables @FM or @AM (which are synonyms - @AM stems from the alternative name "attribute mark"). You can use the Field() function to decompose such a dynamic array - for example the third field is Field(dynarray,@FM,3,1) - but most prefer the "dynamic array notation" dynarray<3>. (There are at least three other ways to extract a field from a dynamic array.
If you've read a record from a hashed file using the MATREAD statement, then each field is in a separate element of the target dimensioned array, and the field mark delimiters have magically vanished (unless your array was not dimensioned sufficiently large, in which case the overflow element may contain some field marks).
In the interest of not confusing you further, I will not dwell on multi-valued fields, except to say that a multi-valued field is a regular field in a dynamic array that contains, instead of an atomic item, contains a list of items (another dynamic array indeed) this time separated by value marks. Value marks can be accessed through the system variable @VM.
Further levels of nesting are possible. The next level is "sub-values". We're not going there!
After you've read a record from a hashed file without multi-valued fields, what you have is a string (technically a "dynamic array") containing all of the non-key fields separated from each other by field marks. Field marks are reserved characters, accessible via the system variables @FM or @AM (which are synonyms - @AM stems from the alternative name "attribute mark"). You can use the Field() function to decompose such a dynamic array - for example the third field is Field(dynarray,@FM,3,1) - but most prefer the "dynamic array notation" dynarray<3>. (There are at least three other ways to extract a field from a dynamic array.
If you've read a record from a hashed file using the MATREAD statement, then each field is in a separate element of the target dimensioned array, and the field mark delimiters have magically vanished (unless your array was not dimensioned sufficiently large, in which case the overflow element may contain some field marks).
In the interest of not confusing you further, I will not dwell on multi-valued fields, except to say that a multi-valued field is a regular field in a dynamic array that contains, instead of an atomic item, contains a list of items (another dynamic array indeed) this time separated by value marks. Value marks can be accessed through the system variable @VM.
Further levels of nesting are possible. The next level is "sub-values". We're not going there!
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Field delimiter for Hash file - what I am trying to do
Thank you for all the previous replies.
I have a hash file in the Unix directory path with one key field and 14 non-key fields. I am opening this file with "openpath" command, reading the record into "PartRec" and then using field function to read 2nd field (non-key). PartitionToLoad = field (PartRec, char(251),2) which returns a null value. I know, the second field has a not null value.
I have tried all kinds of delimiters: @VM, @AM etc...
This works for me if I retrieve the key field. Any suggestions?
I have a hash file in the Unix directory path with one key field and 14 non-key fields. I am opening this file with "openpath" command, reading the record into "PartRec" and then using field function to read 2nd field (non-key). PartitionToLoad = field (PartRec, char(251),2) which returns a null value. I know, the second field has a not null value.
I have tried all kinds of delimiters: @VM, @AM etc...
This works for me if I retrieve the key field. Any suggestions?
From what I recall (it's been awhile) reading hash files from BASIC takes two steps:
1) a READNEXT to get the Key
2) then a READ using the Key to get the data associated with that key
Seems like you may be only doing the first step. Might be prudent to post your code...
1) a READNEXT to get the Key
2) then a READ using the Key to get the data associated with that key
Seems like you may be only doing the first step. Might be prudent to post your code...
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Code: Select all
openpath "whatever" to file
SELECT file
loop while readnext id do
read Rec from file, id then
field2 = Rec<2>
end
repeat
Mamu Kim
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
This is a sharing place, you should publish your solution.
The delimiter used in multi-column key values (you did not specify this in your question) is a text mark, which can be accessed as the system variable @TM.
The delimiter used in multi-column key values (you did not specify this in your question) is a text mark, which can be accessed as the system variable @TM.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.