List of parameters on a MAP

, ,
1

I remember in the old days that when you created a map, internally would create the parameter data area sorted by variable name:

Local MYLDA Library MYLIB DBID 146 FNR 141
Command > +
I T L Name F Length Miscellaneous
All – -------------------------------- - ---------- ------------------------->
1 MYLDA
2 ZZ A 20 INIT<‘ZZZZ’>
2 YY A 20 INIT<‘YYYY’>
2 BB A 20 INIT<‘BBBB’>
2 AA A 20 INIT<‘AAAA’>

This is how is shown when I List the map:

17:05:38 Map MYMAP Library MYLIB (Work) User DBATEST 2008-11-12
0001 * MAP2: PROTOTYPE
0002 * INPUT USING MAP ‘XXXXXXXX’
0003 * MYLDA.AA MYLDA.BB MYLDA.YY MYLDA.ZZ
0004 DEFINE DATA PARAMETER
0005 1 MYLDA.AA (A020)
0006 1 MYLDA.BB (A020)
0007 1 MYLDA.[b]YY /b
0008 1 MYLDA.ZZ (A020)
0009 END-DEFINE
0010 FORMAT PS=023 LS=080 ZP=OFF SG=OFF KD=OFF IP=OFF
0011 * MAP2: MAP PROFILES ***************************** 410***********
0012 * .TTAAAMMOO D I D I N D I D I ?_)

2

After all these years, it still works. Who cares what it looks like internally, as long as it works? How would you like it to look?

3

Not always…because of attitudes like that, I have seen nightmare code all my life.
I would expect to see it internally at least in the order that the fields appear on the map.
When you use CALLNAT, the parameters do match the module being called, so I would expect the pararmeter area of the map to behave the same way… :roll:

Just a thought…Do you know if works like because it was intended like this, sorted or it just happens to be?

P.S. Nothing personal, right now I just have to introduce NATURAL to few Java developers and it is a natural (no pun intended) curiosity for them.

4

Most things are not done without some reasonable intent. I am sure there was much debate in Germany when developing the map editor.

Consider this, I have a working program that inputs a map. My users decide that they would prefer FIELD2 to come before FIELD1 on the page for whimsical reasons. So, I move the fields around and stow the map. With the parameters listed in alphabetical order, that is all I need to do. If instead, the map editor rearranges the parameters based on position, I must also catalog the calling program or abend with a parameter conflict. Or, even worse, say FIELD1 and FIELD2 were the same format: no pda conflict, but until I catalog the program, the fields are passed in the wrong order.

From an aesthetic standpoint, having the parms in alpha order allows me to scan the list for the field name I am interested in.

From another perspective, let’s say I have want to show the same field on the map in three different places. Does it then appear in the PDA three times? Passing it once should be sufficient.

It is good to question why things are done. Far too often we continue in our old habits (or someone else’s) simply because that is the way it has always been done.

5

Could not agree more.

CONSTRUCT used to sort the name of your internal subroutines and that was nice as well.

6

Not to put too fine a point on it, Carlos, but I didn’t ask “Who cares what it looks like?”, I asked “Who cares what it looks like internally?”. Anyone who has seen my code will attest to what a stickler I am for “pretty”. :slight_smile:

The map source is generated by the map editor, and the INPUT USING MAP statement is replaced in the program at compile time. Neither the map source nor the INPUT statement were intended for viewing by a developer. Look at lines 002 and 003 of your map source. That’s the INPUT statement that’s included and cataloged into your program. The field list in the map may not match the LDA, but it does match the INPUT statement in the program.

Consider a map that references not just LDAs, but views and user-defined fields, too.

#A: ___   BB: BBBB________________  #B: ___  ZZ: ZZZZ________________  SSN: _________

When the map source is generated, the parameter list could look something like

1 #A (A3)   
1 MYLDA.BB (A20)   
1 #B (A3)   
1 MYLDA.ZZ (A20)   
1 EMPLOYEE.SSN (A9)

Not all fields in MYLDA are used, so does it help to have BB and ZZ in one sequence or another? If #B is defined in the program prior to #A, should #B be placed first in the parameter list? Should #B be placed before or after fields from MYLDA?

To sequence the MYLDA fields, the map editor would have to scan the LDA source as each field was pasted, to determine its position in the list, or re-read the LDA when it came time to sort the entire field list. A similar process would be needed for the program source for in-stream fields, and for the DDM for fields from a view.

And what happens if the field sequence of the LDA or view changes? Would this require all associated maps and programs to be re-stowed to maintain the sequence?

The only sensible and expedient field sequence is alphabetical.

7

Hi Carlos,

Just to add a comment to those of Jerome and Ralph, if the arguments to a Map, were passed geographically, as you seemed to think they should be, what would you do with arguments that are passed to the Map that do not appear on the map?

I refer, of course, to arguments that will be used in Processing Rules or Helproutines. In the “old” days, we had to “hide” such arguments on a map by making them output only, non displayable. Now, we merely use PF9 in the “field and variable” option, and “roll our own” PDA. Such fields do not appear on the map, but do appear in the PDA.

Thus, they are easy to find and work with, especially since Natural actually indents such arguments to make them more apparent.

steve

p.s. good luck convincing java developers that anything is better than their beloved java (even though Natural is).

8

Ralph:

I think we are both sticklers, thats why I ask… :smiley:

Steve:

I remember the “old days” of Nat 1.X and don’t miss a thing…

About the Java developers, they all come from the same country (!) and are very humble realizing that that at our environment, NATURAL is the “bread & butter” since the main application that tracks ALL the money made, is developed in ADABAS/NATURAL and some BAL & TPF stuff…

9

If you are all sticklers, why do you accept illegal syntax in the generated code?

DEFINE DATA PARAMETER
1 MYLDA.VARNAME (A20)
END-DEFINE

You can’t use “dot-notation” in define data. Why can the map editor do this?

And furthermore: You can have only one DEFINE DATA per program. Why can the map editor use several DEFINE DATA in processing rules? Thats a feature I have always wished to have in internal subroutines!