John/Mark, Mark said: >> How difficult would it be to allow a field to be defined in multiple DSs, >>so that it would point to the same area in storage ? Could you clarify exactly what it is you want to be able to do? Reading this at face value, it sounds not only difficult but technically impossible. So I must misunderstand what you mean. A data structure, by definition, lets you control the memory allocation of subfields. That is precisely what they are good for, and to be able to then manipulate the grouping as a whole. So if a one DS had a given field as (for example) its third subfield, how could that same area in storage also be in another DS with different subfields surrounding it? If you don't base a DS on a pointer or name the DS as a *Entry parm, each DS has its own memory space so subfields could not possibly refer to the same memory location. If you base a DS on a pointer, then you can have multiple DS's with subfields referencing the same area in storage. But I don't think this is what you are asking for. John said: >I asked for this about 6-8 years ago. I believe (can anyone verify this) >that you could do that >with RPGII on the Sys/34-36. Incorrect. If the same subfield name appeared in multiple DS's on the S/34/36, it would generate a warning error for a multiply-defined field. All but the first DS definition were ignored. The other DS's would be large enough to contain the subfield, but program references to the subfield name would refer to only the first DS occurence. If a field was defined both in a DS and as a regular input field or as a C-spec result field but with different attributes (length or decimal positions), it also generated the same warning message. What the compiler assigned was the first definition in a DS (if any). If the same fieldname was used multiple times but was not in a DS, it was given the attributes of the first definition found. >It kinda happens now already if you think about it, If a field is on a DB >file, DSP file, and a D/S >It's almost like having three different quasi structures with the same >variable name with >the same value. Right ? No. In this case there is only one "structure", the DS. There is only one variable with one value. DB or Dspf I/O references the subfield contents of the DS to get or put the field value in the file buffer. RPG is atypical compared to some (most?) languages in how it handles the same field name occuring in multiple files or record formats. Are you perhaps from a COBOL background or other language where you used qualified fieldnames? >The pain is having an Externally defined DS and wanting to use that same >field in another >structure and have them all stay in sync. If you can get by with just one DS (say the DB record format), and let the Dspf/Prtf use some of the same fieldnames but not also make them an externally defined DS, then RPG handles it nicely. If for some reason you must make the DB, Dspf, and Prtf record formats all be externally defined DS's and they use the same fieldnames, then you must use the Prefix() keyword to make the fieldnames unique. There is no equivalent to Cobol's "Move corresponding" verb since RPG does not use qualified fieldnames. Doug * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: firstname.lastname@example.org * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.