Page 1 of 1

Questions asked at Polaris

PostPosted: Wed May 12, 2010 2:49 pm
by give_me_more
Hi,

1). How to lock a particular record in DB2?
My answer: I don't know

2). How to read a particular record in DB2?
My answer: I don't know

3). How to delete all the generation of a GDG without deleting the base?
Earlier I didn't know but now I know.

Answer: By using this step:
//DELETE EXEC PGM=IEFBR14
//D1 DSN=THE.GDG.BASE,DISP=(OLD,DELETE,KEEP)

4). What is static cursor positioning in CICS?
My answer: When we set IC value inside the map it is called statis cursor positioning.

5). When we receive a map, how do we know that data has been entered?
My answer: We check EIBCALEN = 0. If it is zero then it means no data received.

6). When we throw/send a MAP on the screen, at that time what is the value of EIBCALEN?
My answer: Zero

7). In a DB2/Cobol pgm, some modification has been made. That modification is not related to DB2. Like only a DISPLAY statement has been added. Now in this case do we need to go through the entire precompilation/compilation process?
My answer: Yes. Because if we don't go through the entire process again then we will get time-stamp mismatch error.

That's all I could recall ... if I am able to retrace more then I will post it

Please add your thoughts to it as well.

Thanks

Re: Questions asked at Polaris

PostPosted: Wed May 12, 2010 5:32 pm
by Robert Sample
3. Use IDCAMS command DELETE GDG.BASE.NAME.* PURGE
5. EIBCALEN has absolutely nothing to do with maps. When a transaction is started, EIBCALEN gives the length of the DFHCOMMAREA passed to the program. When you do a RECEIVE MAP, check EIBRESP to be NORMAL or MAPFAIL as both values are valid for map receives.
6. EIBCALEN will be whatever value the transaction started with -- SEND MAP has absolutely nothing to do with EIBCALEN and will not affect its current value in any way.

Re: Questions asked at Polaris

PostPosted: Thu May 13, 2010 4:59 am
by dick scherrer
Hello,

In database there are no records. . . They are rows.

1. read with update intent.
2. specify the value of the row you want in the WHERE.
5. modified data tag(?).
7. yes.

Re: Questions asked at Polaris

PostPosted: Thu May 13, 2010 12:59 pm
by give_me_more
Hey D.Sch,

For 5).
I have never worked on CICS. I have only theoretical knowledge of CICS and that knowledge is also limited. In the light of whatever I know, I don't think we use the value of MDT to check whether we have received the data.

Perhaps my question wasn't clear enough. Let me state my question again: When we receive a MAP, then how do we know that there is data in the received MAP?

Thanks for your time.

Re: Questions asked at Polaris

PostPosted: Thu May 13, 2010 4:58 pm
by Robert Sample
From the CICS Programming Guide
The exceptional conditions that can occur on a RECEIVE command are all described in RECEIVE MAP the CICS Application Programming Reference, and most are self-explanatory. One of them warrants discussion, however, because it can result from a simple operator error. This is MAPFAIL, which occurs when no usable data is transmitted from the terminal or when the data transmitted is unformatted (in the 3270 sense--see "Unformatted mode" in topic 4.4.12). MAPFAIL occurs on a RECEIVE MAP if the operator has used the CLEAR key or one of the PA keys. It also occurs if the operator uses ENTER or a PF key from a screen where:

* No fields defined in the map have the modified data tag set on (this means the operator did not key anything and you did not send any fields with the tags already set, so that no data is returned on the read), and

* The cursor was not left in a field defined in the map and named, or the map did not specify CURSLOC=YES.

Pressing ENTER prematurely or a "short read" key accidentally is an easy mistake for the operator to make. In the interest of user friendliness, you may want to refresh the screen after MAPFAIL instead of ending the transaction in error.
If you get a MAPFAIL condition, check EIBAID -- if the ENTER key was pressed then you did not get any data back from the terminal.