View previous topic :: View next topic
|
Author |
Message |
ram_vizag
Active User
Joined: 21 Aug 2008 Posts: 112 Location: hyd
|
|
|
|
Hi,
I 'm changing the attributes dynamically in a program but the same attributes remain unchanged in the screen.
bocoz while recieving the map the attribute values that i have moved or updated was being removed...and all the attributes are having low-values
how to make the updated attribute value to remain as it is updated through the program???
while senduing the map i'm using the code
Code: |
EXEC CICS SEND
MAP('ICPNLSP')
MAPSET('ICGRPSP')
FROM(ICPNLSPO)
DATAONLY
CURSOR
END-EXEC
EXEC CICS RETURN
TRANSID(WS-TRAN-ID)
COMMAREA(DFHCOMMAREA)
LENGTH(44)
END-EXEC
|
and also used only send map code as well...still i could not know why the updated attributes are not remained as they have been moved or updated ???
please suggest becoz the whole program logic depends on this |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
How does this differ from your other post on the same subject within the CICS section of this forum? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Before you issue a SEND and you need to retain data entered in a given MAP field, you must FSET the field's associated attribute.
This would mean when you RECEIVE the MAP, the MAP field Length would be greater than zero and you'd have to re-edit the data again.
The method used in other shops to avoid re-editing map-data, is to place MAP field updates in the commarea and the attribute is left as non-FSET.
When the MAP is then RECEIVED, the only data you'd have to re-edit, would be the data entered and/or changed by the user.
Don't forget to check for erase EOF (DFHBMEOF - X'80') attribute on a given MAP field after a RECEIVE MAP as this indicates the user has changed their mind.
NOTE: Your initial MAP SEND should specify ERASE FREEKB and subsequent MAP SEND's should specify DATAONLY. Both of these concepts are explained in the associated CICS manual. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
I often wonder why CODERs try to be slick,
when they just do not understand what is going on 'under the covers'.
now, I will follow the above verbal abuse with some information:
a CICS map upon assembly will create a copybook (for use in the program)
and a map definition, which is maintained in the cics library.
upon load of this assembled map,
which is read only - it is not ever permanently changed.
the CICS SEND command, causes a 'merge' of the data contained in the area defined by the copybook in the program,
and the map.
thus, attribute changes, as well as data area changes,
are one-time-only.
if you want to maintain a particular 'dynamic attribute',
it must be maintained in the area defined by the copybook.
and since the copybook area is new upon each invocation of the program
(i.e. when the user hits enter)
you will have to populate the attribute bytes accordingly.
i would suggest that in the future you refer to this process as
'on-the-fly map attribute changes'.
dynamic is an overused word. |
|
Back to top |
|
|
ram_vizag
Active User
Joined: 21 Aug 2008 Posts: 112 Location: hyd
|
|
|
|
Bill O'Boyle wrote: |
Before you issue a SEND and you need to retain data entered in a given MAP field, you must FSET the field's associated attribute.
This would mean when you RECEIVE the MAP, the MAP field Length would be greater than zero and you'd have to re-edit the data again.
The method used in other shops to avoid re-editing map-data, is to place MAP field updates in the commarea and the attribute is left as non-FSET.
When the MAP is then RECEIVED, the only data you'd have to re-edit, would be the data entered and/or changed by the user.
Don't forget to check for erase EOF (DFHBMEOF - X'80') attribute on a given MAP field after a RECEIVE MAP as this indicates the user has changed their mind.
NOTE: Your initial MAP SEND should specify ERASE FREEKB and subsequent MAP SEND's should specify DATAONLY. Both of these concepts are explained in the associated CICS manual. |
Thanks a lot Bill,
You mean to say that the attributes that i have updated in the program should be stored in commarea or any other temporary copy book
so again when i recieve the map i have to compare...with the stored once...
But the problem is When Receiving the map the attributes are having low-valeus only and i'm not moving low-values anywhere in the program could you pls help in brief on this.
could you please share Any Material or links with example |
|
Back to top |
|
|
ram_vizag
Active User
Joined: 21 Aug 2008 Posts: 112 Location: hyd
|
|
|
|
dbzTHEdinosauer wrote: |
I often wonder why CODERs try to be slick,
when they just do not understand what is going on 'under the covers'.
now, I will follow the above verbal abuse with some information:
a CICS map upon assembly will create a copybook (for use in the program)
and a map definition, which is maintained in the cics library.
upon load of this assembled map,
which is read only - it is not ever permanently changed.
the CICS SEND command, causes a 'merge' of the data contained in the area defined by the copybook in the program,
and the map.
thus, attribute changes, as well as data area changes,
are one-time-only.
if you want to maintain a particular 'dynamic attribute',
it must be maintained in the area defined by the copybook.
and since the copybook area is new upon each invocation of the program
(i.e. when the user hits enter)
you will have to populate the attribute bytes accordingly.
i would suggest that in the future you refer to this process as
'on-the-fly map attribute changes'.
dynamic is an overused word. |
Thanks Dino,
I could get some thing on sttrbutes...
But still I have a question in my scenario How can i know what sthe previous attributes??
should i maintaion a copy book in commarea
a. prev attributs values (one copy book for these)
b. Current attributs values(the values which i'm updating ????)
Please suggest...
The problem is in my case...only for the fiest time when i'm recieving map i'm having the DFHBMASK value for a field PLANTYPEA . After comparing I'm moving DFHBMPRF(protected and mdt on ) to PLANTYPEA.
So again when i;m recieving and checking i'm seeing low-value('.') in the PLANTYPEA which is getting failed with my logic...here i'm checking for value DFHBMPRF which i could not see...please help on this...
pls provide any example programs or materials or links....Thanks in advance... |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
regardless of FSET or anything else,
I have found thru experience, differences in set-up of terminals,
definition in cics, vtam, router or simply the emulation software
would generally f###-me when i relied on cics instructions to control
the whole shebang.
so, I started (as Bill said), saving what I needed in the dfhcommarea in order
to make a determination in the next session of what went on the the last. |
|
Back to top |
|
|
Peter cobolskolan
Active User
Joined: 06 Feb 2012 Posts: 104 Location: Sweden
|
|
|
|
Quote: |
So again when i;m recieving and checking i'm seeing low-value('.') in the PLANTYPEA which is getting failed with my logic...here i'm checking for value DFHBMPRF which i could not see...please help on this... |
The value of the attribute for a field is NEVER received, just sent from the definition in the map, or what you supply to the A-suffix in your output map structure. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3053 Location: NYC,USA
|
|
|
|
As menioned rightly by Bill you need to get more information on FSET and FRSET, also you might wants to perform the dynamic attribute handling routine every time before you send the map to user, as currently I could say thats happening once at the begining. |
|
Back to top |
|
|
|