I have a Natural Program that redefines a field in a DDM. Such redefinition does not exist in the physical adabas file (or the DDM itself).
I was wondering if this same program would still compile/run correctly without any changes if I add the fields being redefined in the natural program to the DDM and the FDT (i.e. if I create the physical fields in the database)
The example is as follows (just the important bits):
Original Data (FDT + DDM + Program)
FDT
Level I Name I Length I Format I Options I Flags I Encoding
-------------------------------------------------------------------------------
1 I EB I 7 I A I DE,NU I SP I
and it is not being redefined
DDM
0003T L DB Name F Leng S D Remark
0004- - -- -------------------------------- - ---- - - ------------------------
0010 1 EB N-ORDEN-ITEM-EOI A 7 N D
and it is not being redefined
If I change the DDM and FDT to the following, Will the Natural Program Still Work (without any modification)?
FDT
Level I Name I Length I Format I Options I Flags I Encoding
-------------------------------------------------------------------------------
1 I EB I 7 I A I I I
2 I EC I 1 I A I I I
2 I ED I 4 I A I I I
2 I EF I 2 I N I I I
notice that here it is redefined
DDM
0003T L DB Name F Leng S D Remark
0004- - -- -------------------------------- - ---- - - ------------------------
0010 1 EB N-ORDEN-ITEM-EOI A 7 N D
0010 2 EB N-ORDEN-ITEM-XX1 A 1 N D
0010 2 EB N-ORDEN-ITEM-XX2 A 4 N D
0010 2 EB N-ORDEN-ITEM-XX3 N 2 N D
notice that here it is redefined
Are you intending to create a new file with the original field N-ORDEN-ITEM-EOI and the three new fields? Or are you trying to make N-ORDEN-ITEM-EOI into a Group Name?
Either way, the REDEFINE in the view would be incorrect. As coded, the three redefined fields are user defined variables, not database fields. You seem to want to change that and have the three user defined variables become database fields. If you were to do that you would have to redefine the file and reload it.
Why? at present, on the database there is a single L-V (length-value) for N-ORDEN-ITEM-EOI. If the three subfields XX1, XX2, and XX3 were to become fields, they would require three L-V entries in each record (if you were also going to keep the original field, there would now be four L-V entries.
Excellent post, thank you very much. I feel that I didn’t put enough information into my original request.
Let me try to explain the sutiation. We have a current database with the FDT that has that field, without any redefinition. Programs are redefining such field (as shown in the example as well).
I want to create a new database, with a new file, with a new FDT but I want the old field to disappear and be replaced by these three new ones (i.e. a more detailed version of the original field); in this new database I want to be able to run the exact same programs without modifying it (I can recompile them if required).
So, I want the name “N-ORDEN-ITEM-EOI” to be in the “new” ddm just so programs compile.
That is exactly what I want. And since I am starting a new database, I don’t care to modify and reload the file, as long as I don’t need to change my programs.
Okay, this confirms one of my guesses. You want to make N-ORDEN-ITEM-EOI a Group Name. This will likely cause complications.
Take something as simple as MOVE ‘ABCDEFG’ TO N-ORDEN-ITEM-EOI. This will not compile since N-ORDEN-ITEM-EOI is not a field anymore, it is a Group Name. As such some of your definitions, as shown above, would be incorrect. A Group Name does not have a Format or length. A Group Name cannot be a descriptor field, because it is not a field. Basically, a Group Name is an abbreviation, nothing more.
Why not keep the same definitions in the new database, but create sub descriptors for the three subfields? (I noticed you made them descriptors in your definition above). What is it you expect to gain by creating the three fields?
I really think you should fly me down to Antigua and Barbuda. Have scuba gear; will travel.
I can see how bogus this whole thing is. What we are trying to achieve is migrate from Mainframe to Unix our Natural programs. We are facing some problem right now with the conversion of data. When loading data to the UX Adabas, adabas itself takes care of platform conversions (i.e. EBCDIC → ASCII).
The problem is that, as in the example shown here, my client has defined Alfa fields that are not always used as Alfa, which confuses the loader of the UX adabas. I know it sounds hard to believe, but we had some problems while doing a small test migrating data.
I was just wondering if there was any way to redefine the fields as their correct type on the target adabas (UX) in order to have proper (automatic) conversion from EBCDIC encoding to ASCII encoding.
To tell you the truth I do not even know if Adabas can pick up an unloaded file with some structure and load it to a file with some minor changes.
Any ideas here are more than welcome. Sorry, but can’t do the trip to bermuda
Sounds like you haven’t quite described the problem - if the data in the redefined fields is display format (A and N), then it is simply treated as character data and converted accordingly, which will transfer to the Unix platform. That is, for the purpose of migrating, retain the existing structure.
Does that allow you to migrate or are there other issues here that you haven’t described?
Actually, if you try to redefine the data under unix, you may create problems. For example, suppose there is a field defined as A10 on the mainframe. But, in reality, it is a numeric field.
So, suppose you go ahead and manage to create it as a numeric field under unix. What happens now to the code that uses the VAL (alpha field) to “extract” the numeric value. It doesn’t compile is what happens.
I am sure, if we took the time, we could come up with other similar problems. My first instinct would be to try and simply convert the data as is, and the same with the code.
You said in your last post "I know it sounds hard to believe, but we had some problems while doing a small test migrating data. "
