Use of function Key PF7 and PF8 on IMS DC screen

abhiyanta · New User Joined: 18 Apr 2006 Posts: 11 Location: pune

Hi,

I need help from you guys...
my problem is as " I want to Design one IMS DC screen which would be used to browse the DB2 table and also having the functionality like Function keys(PF7) for PAGE UP and PF8 for PAGE DOWN"

Devzee · Posted: Fri Sep 14, 2007 12:08 am

Yes we understood your design.

Is your problem designing this reqt? What is the problem with your design?

What kind of information you are seeking from this forum to help you.

abhiyanta · New User Joined: 18 Apr 2006 Posts: 11 Location: pune

Sandy Zimmer · Posted: Fri Sep 14, 2007 7:45 pm

You can handle that logic within your program. I am not sure what your standards are, but if you give us a look at the first defined fields on your MFS, we can help. Then, you define your MSGIN in your program (in working storage) as message-length 9(04) comp - then IMS-ZZ 9(04) comp. What follows? After that you can define your PFK-ID as pic X(02) with the following 88 levels = enter-key value "00", PFK-01 value "01", etc, etc.

Then when you process the message in your procedure division, you determine your processing logic on which key was pressed.

Sandy Zimmer · Posted: Fri Sep 14, 2007 8:23 pm

Here is an example of an MFS that matches the logic I gave you....

CQ103A FMT
DEV TYPE=(3270,2),FEAT=IGNORE,SYSMSG=OUTMSG2,
PFK=(PFKFLD,'01','02','03',ETC,ETC)
DSCA=X'0000'
DIV TYPE=INOUT
DPAGE CURSOR=((24,01))
DFLD 'CQ103A', POS=(01,02),ATTR=(PROT)
*****REST OF DFLD STUFF*******
FMTEND

*****MESSAGE INPUT DESCRIPTOR*******

CQ103A1 MSG TYPE=INPUT,SOR=CQ103A,NXT=CQ103A2,OPT=2
SEG
MFLD 'CQ103A '
MFLD SECUR1,LTH=09
MFLD SECUR2,LTH=05
MFLD SECUR3,LTH=11
MFLD SECUR4,LTH=08
MFLD FORCHK,LTH=01,FILL=X' 1A'
MFLD (SCREENID,'20')
MFLD (PFKFLD,'00')
*****REST OF MFLD STUFF*******
MSGEND

*****MESSAGE OUTPUT DESCRIPTOR*******

CQ103A2 MSG TYPE=OUTPUT,SOR=(CQ103A,IGNORE),OPT=2,NXT=CQ103A1
SEG
*****REST OF MFLD STUFF*******
MSGEND

abhiyanta · New User Joined: 18 Apr 2006 Posts: 11 Location: pune

thanks this is really heiping ...
I don't have much EXP in IMS.....
plz tell me If I will used scrollable cursor(with HOLD option) for this application, will it be close in between process ( after pressing PF7 then PF8 so on).'

Thanks again.....

Sandy Zimmer · Posted: Sat Sep 15, 2007 6:23 pm

I am sorry, but I do not fully understand your question. The part that I understand is that you will be having multiple screens. Are you using a SPA or are you transaction only? Can you give us your complete requirements.

Devzee · Posted: Sun Sep 16, 2007 9:00 am

Bitneuker · Posted: Mon Sep 17, 2007 4:04 am

You will also need to know (and store) how many pages there are in order to tell the user it's no use pressing PFK-08 for the next screen because he already had it been shown. You also should inform the user about what screen he's on and how many are left; i.e. screen 7 of 15.

MarkArnold · Posted: Mon Sep 17, 2007 4:22 am

If you are only browsing, and the table in not too big, you could retrieve all the rows and use MFS virtual paging to scroll through the data.

Sandy Zimmer · Posted: Tue Sep 18, 2007 12:38 am

If you are doing true transaction processing, you will need to save the database keys from each screen you present. If you are using a SPA, it will be easier, but not as fast and efficient. With no SPA, you would need to leave enough room in your message and on the screen for both the number of the screen you are on and the beginning key value from the database - you would of course need to protect them - hiding them is an option. Remember that working storage is not guaranteed. Your message is. This would allow for an infinite table size - you would not need to be concerned if the table has 20 rows or 20,000. It would not matter. May I suggest that you not use a backward key? How about a field on the screen allowing a beginning key number? You could then code a boolean search key. You need to make your procedure as user friendly as possible.

Sandy Zimmer · Posted: Tue Sep 18, 2007 12:40 am

Well, I always put out a message that indicated that I was at the end of the database. If they wanted to begin again - just press "enter".

Bitneuker · Posted: Wed Sep 19, 2007 12:39 am

@ Sandy:

I think there's nothing wrong with a SPA. The only thing is how you define it. Think of SPA as 'logical'; it might be in memory, message, disk or a database. The idea of a Scratch Pad Area is you keep information stored during a conversation in order to know how to proceed the dialog. The way you solve it is your own choise. The idea of SPA is nothing more than storing information in a conversation. I have developed systems using a 'logical' SPA without GU or ISRT from/to the message queue via IO-PCB.

Sandy Zimmer · Posted: Wed Sep 19, 2007 12:45 am

It depends on what the standards are - a slower paced environment would allow a spa - they used them when I first learned IMS. Fast forward to a fast paced high transaction processing environment and they said absolutely NOT! Certain vendors trying to sell the bank packages with SPAs and the bank said NO WAY! It is not always a choice. I think that it is important to keep in mind the standards along with speed and number of users accessing the system.

Bitneuker · Posted: Wed Sep 19, 2007 4:07 am

Did you realy understand my message? SPA = logic not the way you store it.

Bitneuker · Posted: Wed Sep 19, 2007 4:16 am

In addition to that............ keeping track of your position in the database is , like your said before, life guard. But one should also look at the benifits of good use of command codes. Straight forward calls and multiple PCS's could be costly and solved by intelligent DB-design like SI or defining a logical DB with bi-directional pointers. As far as I'm concerned it's all about data management (analysis and structuring).

Sandy Zimmer · Posted: Wed Sep 19, 2007 4:18 am

Yes, I did indeed understand your message. My analysis is "why use a spa if you do not need to". Virtual and disk spa areas still bog down a fast paced system. Memory is a resource - as is virtual storage - as is disk space. Why use it if you do not need to? CICS is one reason many fast paced transaction processors went to DC.

Bitneuker · Posted: Wed Sep 19, 2007 4:34 am

I'm not talking about virtual or disk SPA.......just the logic of a SPA. You can store you intermediate results wherever you lik (like a self defined SPA database). All I want to say is that a conversational program will allways need some kind of 'remember where I was and what to expect next'. My message is to not turn away from conversational but when you go conversational do what is best like in golf; play the ball as it lies and if you can't do what is fair.......... Messure your data and needs and after that make your decsison; saying one should alsway turn away from some kind of SPA is like jumping in a black hole. SPA is logic and not physical.

Bitneuker · Posted: Wed Sep 19, 2007 4:37 am

BTW: it's 1:06 in the night so I turn in. See you all tomorroy

Sandy Zimmer · Posted: Wed Sep 19, 2007 5:15 am

OK - George - tomorrow! It is only 7:45pm here EST in the states. My last word is that you can store where you were in your message - non-display fields in your message on your screen - in your MGS - - the way I did it. You never need to worry about someone else getting your message - which I saw in instances of bringing in CICS people to do IMS DC work - oh dear! They thought that their working storage was a guarantee - imagine that! These people brought the system down.

Bitneuker · Posted: Wed Sep 19, 2007 3:17 pm

Sandy, we don't disagree at all. I tried to point out the importance of the logic of keeping intermediate results save. For this you can indeed use the SPA or whatever. CICS-people are spoiled with their comm-area and it's pretty hard to understand IMS/DC if you're not educated in this. Who understands that you have to init all variables, switches and the lot before processing of a message starts because one single occurrence of an application serves hundreds of terminals? I myself once forgot to init a switch (and retain it from SPA) resulting in wrong processing; it was quiet in the region so the MPP stayed in the region with the switch set by another terminal

So my point is not how store intermediate results but the logic of it.

Sandy Zimmer · Posted: Wed Sep 19, 2007 5:01 pm

Yes, George we do not disagree. It is tricky, but I did it with hidden fields on the screen. While testing, you can make them displayable. I then checked those fields immediately after I retrieved the message. It is a lot more work and requires a lot more analysis. If you plan to work for a high transaction processing employer, it is good to know. Actually, it can be fun!

Bitneuker · Posted: Thu Sep 20, 2007 12:22 am

Sandy Zimmer · Posted: Thu Sep 20, 2007 12:32 am

OK George. If you are invoking your transaction from a main menu, you cannot usually combine a SPA system with a straight transaction processing system. Take my word - there is a way by manipualting something in your MFS, but it is not a simple solution. Most high security systems run from a main menu for security purposes. Sometimes that is not enough - for instance payroll/personnel systems. I wrote a security system in addition and was able to determine who and what level of security they had - I assigned it - then when the system was installed, the MAIN PERSON assigned it. I was then able to maybe give them access to the system and certain screens, but not display (hide) certain sensitive fields.