|
View previous topic :: View next topic
|
| Author |
Message |
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
I have developed a map that has a field that is defined as dark. Under certain circumstances, I need to programmatically change this field to normal; then back to dark once the condition has been satisfied.
It is not a message field - defined elsewhere in the map, but a "MORE: - +" to show the user that their look up request has retrieved more data than can be shown on the screen at the same time.
Now the question: What values are used to change the attribute from dark to normal - while keeping the field protected? I have the DFHBMCA, but was not certain which value would accomplish this.
I am leaning towards ATTR-PROT to show the field and then ATTR-PROT-DRK to hide it again. Is this correct? |
|
| Back to top |
|
 |
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Sounds like it to me, without searching up the BMS manual....Give it a try and see.
BTW, you said "I am leaning towards ATTR-PROT....." which kinda implies thinking of other methods, what else was in the mix? |
|
| Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
Well, the -MDT fields caught my eye. And as mentioned in the documentation, the copybook is fairly cryptic.
Ah! Texts that are 30 years old when we were limited to 8 character names!
The option suggested in-house was using another map with these two fields defined in addition to all the other fields. Before you scoff, bear in mind that the system I have been hired to support is written in CICS Conversational mode! Scary, very scary. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| socker_dad wrote: |
| And as mentioned in the documentation |
I'll get a solid answer if you could give me the doc name or number so I can find it.
| Quote: |
| The option suggested in-house was using another map with these two fields defined in addition to all the other fields. |
Definetly not needed.
| Quote: |
| Before you scoff, bear in mind that the system I have been hired to support is written in CICS Conversational mode! Scary, very scary. |
Are you sure you didn't mean pseudo-conversational? Now THAT's scary.....  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
| And we'll re-activate MACRO level . . . . |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| dick scherrer wrote: |
| And we'll re-activate MACRO level . . . . |
That's what I cut my teeth on macro level assembler pseudo-conversational running on slow 4800 lines in an underpowered page thrashing trailing-edge 135..... 
Geez, it's great to be (somewhat) current....  |
|
| Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
"Are you sure you didn't mean pseudo-conversational? Now THAT's scary....."
Nope - the transaction starts and stays resident for the entire life of the program. No swapping out while waiting for the user. Incredible waste of system resources. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Yea, but a breaze to code..... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
COMMAREA - we don' need no stinking COMMAREA - we'll just use our local program storage. . . . and wait for a response. . . .
And maybe we'll encourage/allow users to leave things locked while they go to lunch too. . .  |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Now, now, Dick, don't hold back, tell us how you really feel..... |
|
| Back to top |
|
|
|
|
