Use of extended attributes in IMS/DC 1

[Jimanderin]

Hi

I have a screen which uses extended attributes in the MFS. When I put the screen onto a terminal with the attributes set (protected, dark, MDT) they behave as I intended.

But, when I receive the screen MFS back into my program the extended attributes have gone and have been replaced by spaces.

So, I then have to set them back up again in the logic (I am coding in COBOL), before sending the screen to the terminal again.

Does anyone know how to retain the extended attributes when a MFS message is 'got' into a COBOL program.

I am using SDF2 to define the screen.

Any pointers would be most appreciated. I have ploughed through the IBM manuals with no joy so far.

Regards
Jim

 

[Dimandja]

Hi Jim,

I am not a mainframer, but I am responding only because no one (better qualified) has answered you yet.

My understanding of MFS (Message formatting service) is that it is specifically designed to maximize the traffic speed between host and terminal. MFS does this by sending only the needed information.

For example, screen attributes are only used by the screen. This means that it would be (by design) a waste of resources to ferry this information back to the host (your COBOL program).

As a matter of fact, you should only be getting modified fields back from the terminal: headings, labels and unmodified fields should not be going back to your program. All in the name of efficiency in traffic control as provided by MFS.

Dimandja

 

[Jimanderin]

Dimandja

Thanks for the reply. I have been looking through manuals for hours looking for an answer but I could only find subtle hints about attributes not being sent back.
Your reply was succinct and has enabled me to get on with the job.
Thanks
Jim

 

[BetsyB]

If you can use the same working storage for receiving and sending the screen information - you're sending the bytes for the attributes both ways. (Your mfs can be defined to send them or not, your program just has to be set the same way.)

What's more common at the shop I work at is that the attribute space used for sending the information back into your program is initialized as spaces.

Remember that your data fields won't even make the round trip back into your program if the attributes aren't defined as mod. I wouldn't expect you to be able to define an attribute for an attribute.

If the normal usage for a field is dark or protected you may want to consider setting up those specific fields that way in the format and only programmaticly overriding it under special circumstances.