IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

How to fetch the IMS Field into WSS variable


IBM Mainframe Forums -> IMS DB/DC
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
garv_fundu
Warnings : 1

New User


Joined: 02 Nov 2006
Posts: 22

PostPosted: Mon Dec 11, 2006 3:50 pm
Reply with quote

Hi all,

Suppose currently we are at record no 102 in a database which has a segment A as root seg with a field membership no, then how do we fetch that information in a working storage variable... what i mean is how do we read that membership no?

please clarify...[/i]
Back to top
View user's profile Send private message
Bitneuker

CICS Moderator


Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19

PostPosted: Mon Dec 11, 2006 4:44 pm
Reply with quote

First please clarify how you access the database. Are you using an application executing DLI-call? If so, the IO-area (last parameter in your DLI-call) contains the segment. Of course this should be a sensitive field in your PCB.
Back to top
View user's profile Send private message
garv_fundu
Warnings : 1

New User


Joined: 02 Nov 2006
Posts: 22

PostPosted: Mon Dec 11, 2006 6:05 pm
Reply with quote

Bitneuker wrote:
First please clarify how you access the database. Are you using an application executing DLI-call? If so, the IO-area (last parameter in your DLI-call) contains the segment. Of course this should be a sensitive field in your PCB.



Yeah i am accessing the database thru DLI calls...
i know that io area contains the information but is there any way we can retrieve the information in case the io area has been reset after the call to a particular record is made...

i.e. to retrive the info of the current record in the database
Back to top
View user's profile Send private message
Bitneuker

CICS Moderator


Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19

PostPosted: Mon Dec 11, 2006 6:30 pm
Reply with quote

You might consider to save the IO-area before the next call is made. You might use a different IO-area for your next call. If the segements are in the same structure you might consider a pathcall or, if the desired field is a key field you might find it in the key feedback area. You might use multiple positioning also. If it's an MPP you might store it in the SPA. It all depends on how your application operates and that's what remains unclear to me.
Back to top
View user's profile Send private message
Nighthawk750

New User


Joined: 04 Nov 2006
Posts: 20
Location: Amsterdam

PostPosted: Mon Dec 11, 2006 6:45 pm
Reply with quote

garv_fundu wrote:

Yeah i am accessing the database thru DLI calls...
i know that io area contains the information but is there any way we can retrieve the information in case the io area has been reset after the call to a particular record is made...

i.e. to retrive the info of the current record in the database


The only reason why an IO area will be reset is after another IMS call (in normal circumstances). So as long as you do not overwrite the contents of the IO with another call, the IO wil remain intact.

The current record will be the one in the IO.
Back to top
View user's profile Send private message
Bitneuker

CICS Moderator


Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19

PostPosted: Mon Dec 11, 2006 6:50 pm
Reply with quote

Nighthawk: I see this as a confirmation of my 2 cents. But we still don't know how the application operates. Maybe topic starter will supply that information so we can serve him/her better icon_wink.gif
Back to top
View user's profile Send private message
garv_fundu
Warnings : 1

New User


Joined: 02 Nov 2006
Posts: 22

PostPosted: Mon Dec 11, 2006 7:49 pm
Reply with quote

Bitneuker wrote:
Nighthawk: I see this as a confirmation of my 2 cents. But we still don't know how the application operates. Maybe topic starter will supply that information so we can serve him/her better icon_wink.gif


actually this is in relation to checkpoint restart logic...
suppose am at 125th rec and there occurs an abend...
on restarting, the application starts from 100th rec..(as a checkpoint is inserted after evry 100th rec)
at that time if i want to retrieve the info of the current rec in a variable then what do i have to do as io area will contain info about 125th rec only....


And what if i issue a GU call without any ssa... will it fetch the info of the current rec in the io area?
Back to top
View user's profile Send private message
Nighthawk750

New User


Joined: 04 Nov 2006
Posts: 20
Location: Amsterdam

PostPosted: Mon Dec 11, 2006 8:17 pm
Reply with quote

garv_fundu wrote:

actually this is in relation to checkpoint restart logic...
suppose am at 125th rec and there occurs an abend...
on restarting, the application starts from 100th rec..(as a checkpoint is inserted after evry 100th rec)
at that time if i want to retrieve the info of the current rec in a variable then what do i have to do as io area will contain info about 125th rec only....


And what if i issue a GU call without any ssa... will it fetch the info of the current rec in the io area?


As for you last question: if you issue a GU without an SSA, this is a special call to read the first root from the DB. That is, the root with the lowest key value. So I doubt this call will be of service to you after an abend.

After the abend you have to insert an XRST call. That call will provide you with the key information to issue a qualified GU-call. After that call you will probably have to make a GN-call. Then you are at the point were you left off (not the abend point, but one record after the last CHKP).

Hope this helps.
Back to top
View user's profile Send private message
Bitneuker

CICS Moderator


Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19

PostPosted: Mon Dec 11, 2006 8:23 pm
Reply with quote

Nighthawk: correct icon_wink.gif

TS: One more cent: if your application abends you have no IO-area at all left; just a memory dump. Could you explain why you want the content of the abending segment? Is it for debugging purpose or what? You should find it in the dump.
Back to top
View user's profile Send private message
garv_fundu
Warnings : 1

New User


Joined: 02 Nov 2006
Posts: 22

PostPosted: Tue Dec 12, 2006 10:18 am
Reply with quote

Let me be clear this time....

This is in relation to checkpoint restart logic...
suppose am at 125th rec and there occurs an abend...
on restarting, the application starts from 100th rec..(as a checkpoint is inserted after evry 100th rec)
at that time i have to insert a checkpoint again....
this will result in the loss of database position....
so after the chkp insertion how do i move back to the 100th rec....

also ain't there any call which retrieves the info about current rec only....
Back to top
View user's profile Send private message
Nighthawk750

New User


Joined: 04 Nov 2006
Posts: 20
Location: Amsterdam

PostPosted: Tue Dec 12, 2006 12:15 pm
Reply with quote

garv_fundu wrote:
Let me be clear this time....

This is in relation to checkpoint restart logic...
suppose am at 125th rec and there occurs an abend...
on restarting, the application starts from 100th rec..(as a checkpoint is inserted after evry 100th rec)
at that time i have to insert a checkpoint again....
this will result in the loss of database position....
so after the chkp insertion how do i move back to the 100th rec....

also ain't there any call which retrieves the info about current rec only....


If you issue a CHKP-call every 100th record, that means after every 100 records *read*. If you start after an abend, you will eventually begin at record 101. So in this case your first CHKP after the abend will be at record 200. The logic in you program should be something like this (after the abend)
Make an XRST call (this will retrieve the record of the last CHKP taken)
Read the next record (GN)
Continue processing.
After 100 processed records, make the CHKP call
etc.

One more thing about the checkpoint counter: after an abend that counter should be reset to zero.
And one more thing about losing your database positiion:
you FIRST reposition, THEN you will make any new CHKP calls.

Hope this helps.

Marc
Back to top
View user's profile Send private message
garv_fundu
Warnings : 1

New User


Joined: 02 Nov 2006
Posts: 22

PostPosted: Tue Dec 12, 2006 2:17 pm
Reply with quote

If you issue a CHKP-call every 100th record, that means after every 100 records *read*. If you start after an abend, you will eventually begin at record 101. So in this case your first CHKP after the abend will be at record 200. The logic in you program should be something like this (after the abend)
Make an XRST call (this will retrieve the record of the last CHKP taken)
Read the next record (GN)
Continue processing.
After 100 processed records, make the CHKP call
etc.

One more thing about the checkpoint counter: after an abend that counter should be reset to zero.
And one more thing about losing your database positiion:
you FIRST reposition, THEN you will make any new CHKP calls.

Hope this helps.

Marc[/quote]


Actually i am inserting the CHKP after processing 100 recs but only after 101st rec is successfully accessed...
so after restart, my database position will be again at 101st rec...
so i cannot use GN call then....

nd since i have to start processing 101st rec hw to store its info before i place a new chkp (in my application it is mandatory to place a chkp again after XRST call)....


i hope u r gettin me...
Back to top
View user's profile Send private message
Nighthawk750

New User


Joined: 04 Nov 2006
Posts: 20
Location: Amsterdam

PostPosted: Tue Dec 12, 2006 2:41 pm
Reply with quote

garv_fundu wrote:


Actually i am inserting the CHKP after processing 100 recs but only after 101st rec is successfully accessed...
so after restart, my database position will be again at 101st rec...
so i cannot use GN call then....

nd since i have to start processing 101st rec hw to store its info before i place a new chkp (in my application it is mandatory to place a chkp again after XRST call)....

i hope u r gettin me...


The general rule of making checkpoint calls is that they are done after complete processing of a record.
If I understand your description correctly, you do this:
read record 100
process record 100
read record 101
checkpoint
process rec 101

Well, this should work also. In that case you do not have to make a GN-call. That GN call is only necessary when you make CHKP calls after processing of the record. Just an XRST in this case will do.

And concerning the mandatory CHKP call:
After making an XRST call, your only option is to reposition before making your CHKP call again. XRST and repositioning (GU-call) go hand in hand.
If for some strange reason you realy have to make a CHKP call before repositioning, you could move the IO contents of the XRST call to a working storage field.

Hope this helps.

Marc
Back to top
View user's profile Send private message
garv_fundu
Warnings : 1

New User


Joined: 02 Nov 2006
Posts: 22

PostPosted: Tue Dec 12, 2006 3:23 pm
Reply with quote

Nighthawk750 wrote:
garv_fundu wrote:


Actually i am inserting the CHKP after processing 100 recs but only after 101st rec is successfully accessed...
so after restart, my database position will be again at 101st rec...
so i cannot use GN call then....

nd since i have to start processing 101st rec hw to store its info before i place a new chkp (in my application it is mandatory to place a chkp again after XRST call)....

i hope u r gettin me...


The general rule of making checkpoint calls is that they are done after complete processing of a record.
If I understand your description correctly, you do this:
read record 100
process record 100
read record 101
checkpoint
process rec 101

Well, this should work also. In that case you do not have to make a GN-call. That GN call is only necessary when you make CHKP calls after processing of the record. Just an XRST in this case will do.

And concerning the mandatory CHKP call:
After making an XRST call, your only option is to reposition before making your CHKP call again. XRST and repositioning (GU-call) go hand in hand.
If for some strange reason you realy have to make a CHKP call before repositioning, you could move the IO contents of the XRST call to a working storage field.

Hope this helps.

Marc



thanks a lot....

one last thing ain't there any call which does not move the database positon... i mean we stay at the current segment or record...
Back to top
View user's profile Send private message
Nighthawk750

New User


Joined: 04 Nov 2006
Posts: 20
Location: Amsterdam

PostPosted: Tue Dec 12, 2006 3:48 pm
Reply with quote

In normal circumstances the position will be changed after an Get, Delete or Insert call.
Only after Replace the position stays on the current record.

You can, if you want to, use multiple positions if you use this option in de PCB definition. As far as I know that option is not used that often.
Back to top
View user's profile Send private message
Bitneuker

CICS Moderator


Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19

PostPosted: Tue Dec 12, 2006 4:14 pm
Reply with quote

Nighthawk: multiple positioning like I said before may be an option indeed. For TS: take a look at this manual and search for "multiple positioning", it shows you all including examples. I strongly advise to read this book frequently icon_idea.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> IMS DB/DC

 


Similar Topics
Topic Forum Replies
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
No new posts Replace Multiple Field values to Othe... DFSORT/ICETOOL 12
No new posts Fetch data from programs execute (dat... DB2 3
No new posts Variable Output file name DFSORT/ICETOOL 8
No new posts Join 2 files according to one key field. JCL & VSAM 3
Search our Forums:

Back to Top