Dynamically create a field - Based on the format of another field

Hey All,

I am working on a tool and got stuck at this point.

Let me explain what I am trying to do.

I created a map which will be populated with database fields. These fields can be of any format N3.2 or A10 or anything.

Now I am planning to create an utility using which I can update these database fields. The problem here is that, as I said earlier, we won’t know the format of any of these fields beforehand.

To be more specific. #I may consist 5.341 ( N1.3), but I chose a common format A40 for displaying. So is there a way to create a field dynamically based on the value in this field.

Let me know if you have any questions


Steve will be along soon to tell you you need training, and he will be right.

Read the manual about MASK processing

Giles - I don’t think it is that straight forward.

So you say using an Edit Mask, I can create a variable #B with the same format as #A ?

We have no clue what the format of #A is… ( It is A40 default)

I don’t really want to know too much about what you are doing, you need to work it out.
but you can use the MASK to check the contents of your field. That MASK can be a variable.
You can REDEFINE a field into an array of bytes and check each byte individually. As I say you need to work out to solve your problem.
Look at MASK
MASK Option - Check Selected Positions of a Field for Specific Content


operand1 IS (format)

As was previously stated a combination of MASK and IS - as well as EM for the result would achieve what I think you’re trying to do.

As an example:

1 #A (A40)
1 #HB (A5)
1 #B (N2.2)
#A := ‘14.72’
IF #A IS (N2.2)

However, you do need to have some understanding of the potential values that could be entered in order to make this work. On the other hand that’s something you always need to know if you’re going to program in any language even the loosly typed ones.

If you are trying to create additional variables within an executing program, then the answer is a resounding NO.

If you are dynamically building source to be RUN, then you really don’t need to worry about the input data format. Leave that responsibility to the user providing the values.

*** soap-box ***

I have met many mainframe programmers who believed that they could create such a general-purpose utility, most of them encouraged by their (limited) knowledge of dynamic code generation. A little bit of knowledge can be dangerous. All but one of these programmers failed in their attempts. You need in-depth knowledge of Natural, Adabas, and Predict to get even close. Save yourself a lot of grief. Shelve the idea.

ps The one mainframe success story is the product PEEK.

Hi Vasanth (and hi Giles, I was busy on something else :smiley: )

I thought I understand what you are trying to do, but eventually, you lost me.

I really did not understand this at all.

Why does your map not have one variable for every field in the ddm? Are you trying to squeeze all the fields into one screen’s worth of space? Hopefully you are aware that a Map size is constrained only by LS and PS, which means you can have a map of upto 249*250. I would guess that this would suffice for the number of fields in the ddm.

Even a modest sized map, say four screens big (158*46) would probably suffice. You can equate %W commands to PF keys to facilitate navigating around the map.

Suppose you have a View in your program with all the fields of the ddm. Suppose the fields are named F1:F120.

You go into the map editor and type P progname in the control block at the top left.

You “design” your map by entering :1 :2, etc on the map, positioning the fields where you want them.

You now have a single map that will permit modification of any/all the fields in the view.

If this interpretation of what you are trying to do is incorrect, please try conveying the essence of the “tool” again.

Thanks All for the replies.

As suggested by few, I will go through the natural documentation again.

HI Mick,

As you said, I won’t know the potential format values. So that’s the difficult part :slight_smile:
Thanks for code

Hi Ralph,

Our project is already using the tool created ( Which has the basic functionality of displaying the fields). So just thought if I cud extend it to have Update utility.

Hi Steve,

I thought explaining about the tool will confuse everyone and hence just gave my requirement, which really didn’t help :slight_smile:

Below is the tool I created for accesing database fields, an year ago. I just released the initial version then and hence using this tool we can only display the fields. I attached the basic screenshot.

The logic is to create below script dynamically using RUN.

“Read the database, Accept/reject criteria and display the fields”.

I used a default of A40 for all display fields. Since I used a display, the field is displayed in correct format and no issues at all.

And then now I am thinking of creating the next version using which I can update the selected fields from the display.

If you see the attachment 2 (Update), I will first display the value of a field in modifiable map fields (If you see the attachment - A030299969, D, CD)and then allow to modify over it.

So I created few map fields UPDATE-1, UPDATE-2…

If +I (Defined as A40) consists of the field name #PRICE. &I consists of the value 10.35. (+I is used for passing field name to the dynamic program. &I while displaying)

In the Update module first we move &I to Update-1 (The fields Update-1, Update 2… are defined as A40 since I won’t be able to guess the format of the database field format). This will display the field value in the Update screen.

The problem occurs when I move Update-1 (A40) ( which consists of 10.35) to the real database field PRICE (N2.2) for updating.

Update-1 can be anything. Date, Time, N3.4, N10 …anything. So I don’t see a way how this can be generalized, because using the tool we can read all the database files and respective fields. We can’t guess the format of the field that is selected.

Just thought of giving you more details. I will read some documentation and see what can be done. May be with this design Update may not be possible I guess.


Granted, if you were to build a general-purpose update utility, you would start with inquiry functionality, but why would you build an inquiry utility when Natural has one built-in?

Tools → Development Tools → Data Browser

Hey Ralph,

Could you please let me know where or how to access these tools?

By Tools → Development Tools → Data Browser do you mean in the softwareag site?


From the screen snaps you posted, it appears that you are taking a whole screen to present a single record at a time.

This is exactly the scenario where the use of external maps would be appropriate. The Map would contain all the fields from a file ddm. To present the data you could use a WRITE … USING MAP statement. To update the records, you would use an INPUT USING MAP.

If you want to restrict update capability, you could use the protect option (or just AD=O). You could highlight fields using control variables for various (or even all) fields.

As noted above, in my earlier post, you could use PF keys to navigate around the logical page (defined by PS and LS).

WARNING. You do not want to simply give end users access to modify all the fields of a record. They will destroy the integrity of the database. For the fields they do have update access, make sure you spend a lot of time validating the values they input. You might make use (where appropriate) of selection boxes to restrict the values they can enter.

Additional WARNING. Actually, a repeat of Ralph’s warning. This will be a LOT harder than you may think it is.

Got your point Steve and Ralph,

I will shelve this second version :smiley:

And thanks for the detailed explanation.

I seriously feel good, discussing tech stuff with you guys :slight_smile:

“Tools” is found on Natural’s menu bar.