Joined: 21 May 2009 Posts: 139 Location: United States
Hi All, am facing u0260 abend while transferring data from ims screen to my pgm variable. I am providing the MFS layout here and the pgm variable layout as well. I am not able to identify where there is a length mismatch-
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
I haven't gone thru it all yet, but why do you have 1700 bytes of filler at the end of your message? You know that the shorter message you send, the more efficient. Get rid of the 1700 bytes.
Joined: 21 May 2009 Posts: 139 Location: United States
thanks for putting in your time Sandy. I'll do that, but a doubt is- it is the receiving field, I have kept that just for now to avoid any truncation of data if happening. Let me know further amendments to be done.
Joined: 21 May 2009 Posts: 139 Location: United States
Cursor fields I gave just to put the stuff in sync with MFS, are they not needed? They are optional I guess. Attribute bytes we have been using as x(2).It works.
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
When you position and flag a field in error what are you sending to the attribute field? For instance, your numeric field is in error. You want to position the cursor at that field - so you move unprotect-num-hi-mod curs (PIC 9(5) comp value 49371) to the output attribute byte field in your output message.
Joined: 21 May 2009 Posts: 139 Location: United States
Sandy we are using redefines for the (PIC 9(5) comp value 49371) and putting them in Alphanumeric ones- X(4). We are using these alphanumerics in the code and not the comp values directly. Thats a standard we follow.Is it making sense to you?
Joined: 21 May 2009 Posts: 139 Location: United States
you mean whatever is in i-o-lterm-pcb or the IO-PCB ? I tried to see that IO-PCB but didnt succeed. Its not accessible or something. Had I got that it would have been possible to compare the stuff with my message-segment. You are talking in that direction ..right ? But I'll again check with the systems ppl if I cud get to it.
Joined: 21 May 2009 Posts: 139 Location: United States
ok you mean to have separate variables to receive and send the maps to screen from program? that can be done but my first problem is to receive it properly. its failing.Is there a problem with attribute definition?
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
Please define a input working storage area for your input message - it will not contain any attribute bytes. Your output message will contain the attribute bytes. After you've checked for no-more-messages (QC), or any other awful return status code - then move your input data - field by field - into your output message area - which will contain attribute bytes. Always do full screen editing - when you find an error, then you set the attribute bytes, but keep editing all the fields.
Joined: 21 May 2009 Posts: 139 Location: United States
Here in my MFS I have a field with length 4 and attribute 2 bytes, hence in MFLD its total 6 bytes, so in my I/P wrkng storage how will I receive it w/o having a 6 byte variable[x(2) + 9(4)] ? or in the MID should I make it a 4 and in MOD keep it as 6 ? and correspondingly define the I/P and O/P wrkng storage ?
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
A couple of questions - you are using procedure division USING - is this a subroutine of some calling program? If not, why are you using it? I just looked at your MFS - you have attribute bytes assigned in your MID - why? Did you copy that from someone else?
. Pls let me know if anybody can detect a mismatch.
