AS/400 Subfile – Strange error

895 pts.
Tags:
AS/400 Subfiles
Subfiles
Hi there...

I'm getting a strange error in subfile...

I've declared 2 columns side by side as below

A            OENNOCD        5A  O  9 37                            A            OENFQCD   R        O  9 44                           

variables are the DB file field names...so when i fetch cursor into a datastructure which is defined as

 * Input Table/View Fields                                   d  wOEFPGRDNV1  e ds                  ExtName(OEFPGRDNV1)   

In debug the variable OENNOCD = 'BLACK' however in subfile it displays first letter B then all spaces and in the next column for OENFQCD, it displays 'LACK' ......

I've not set up any other attributes for those columns...still only this column behaves the strange way out of all other 7 columns.

Please help...

thanks,

nutan.



Software/Hardware used:
AS400

Answer Wiki

Thanks. We'll let you know when a new response is added.

Look at your compile listing.
See if Field names are really the same.
Check to make sure you are using the correct DSPF.
Check your DS subfields

Is there anything in your DSPF that is overlaying those positions in line 9?

Discuss This Question: 16  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    * Input Table/View Fields d wOEFPGRDNV1 e ds ExtName(OEFPGRDNV1) Although that's nice to know, it doesn't tell us anything about how OENNOCD and OENFQCD are defined. Please copy/paste the generated I-specs for those fields into a CODE-block here. Also, please verify whether or not either of those fields has multiple definitions such as both 'Input' and 'Output'. Tom
    125,585 pointsBadges:
    report
  • Nutangujar
    Thanks Charlie. I checked all that thrice....I checked if there is any hiddedn or non display fields...................I also adjusted spacing to keep more space b/w two fields...it still splits the OENNOCD such that it display first character in the right column and remaining 4 characters in the next column....Is there a possibility of having any hex codes in between which introduce spaces between a word and makes word BLACK to display as 'B LACK' ????????? to add to above ....the columns next to this problem column get ruined and introduce some wierd values such as 00, 29 at the beginning of the data.... All sounds really wierd....
    895 pointsBadges:
    report
  • Nutangujar
    Hey Tom, here is this I-spec generated in compile listing for DB file * Input Table/View Fields d wOEFPGRDNV1 e ds ExtName(OEFPGRDNV1) *--------------------------------------------------------------------------------------------* * Data structure . . . . . . : WOEFPGRDNV1 * * External format . . . . . : OEFP_00001 : TESTITG/OEFPGRDNV1 * * Format text . . . . . . . : FORMAT0001 * *--------------------------------------------------------------------------------------------* D OENNOCD 5A Nursing Order Code D OENFQCD 4A Frequency Cd I spec generated for Subfile record format in compile listing *--------------------------------------------------------------------------------------------* * RPG record format . . . . : DTL01 * * External format . . . . . : DTL01 : TESTITG/NC0M86FM * * Format text . . . . . . . : Detail Record * *--------------------------------------------------------------------------------------------* I S 1 6 0OENAUDT6 I S 7 10 0OENAUTM4 I A 11 20 OENAUUID10 I S 21 23 0OENDSEQ I A 24 28 OENNOCD I A 29 32 OENFQCD I S 33 34 0OENOCCU I A 35 42 OENPRCD8 I A 43 92 OENCOMT I A 93 93 OENPFST ..................... they all are output only fields.
    895 pointsBadges:
    report
  • CharlieBrowne
    You said Is there a possibility of having any hex codes in between which introduce spaces between a word and makes word BLACK to display as ‘B LACK’ ????????? to add to above ….the columns next to this problem column get ruined and introduce some wierd values such as 00, 29 at the beginning of the data…. All sounds really wierd…. == That does sound to me you are getting some hex characters in your buffer. * Can you email the source for the DSPF and RPG to me? Charlieb@themembersgroup.com
    41,380 pointsBadges:
    report
  • CharlieBrowne
    Also, send the full compile listing with the source. Thanks
    41,380 pointsBadges:
    report
  • TomLiotta
    Those variable definitions look okay. So, next is to verify that the compiled object has the same definitions as what is included in the compiled program. Use DSPFFD against the display file and look at the field definitions. Do they match with what is compiled into the program? Be aware that recompiled display files might be copied into QRPLOBJ which could give two versions of the object. Also, activation groups might have versions of objects that are different from what's in the library. And, of course, there might simply be different copies of objects in a library list. Finally, just to be certain... Have you actually looked at the data in the file to make certain that it isn't messed up? You might want to use DSPPFM to be sure. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    I supect that the problem is in the SQL and the data structure. SQL is something like Select * from ... Fetch into wOEFPGRDNV1 And that wOEFPGRDNV1 isn't providing the same structure as the data from the Select command. Phil
    49,850 pointsBadges:
    report
  • TomLiotta
    SQL is something like Select * from … With the original comment ("fetch cursor"), that's a possibility. The compile shows library TESTITG, which might not be the run-time library. SQL wouldn't see the same 'level check' as native I/O. If the runtime library file has a new CHAR(1) field before OENNOCD in the buffer (or perhaps a field length was increased), the "SELECT *" could mess things up good. That's a definite reason for never using "SELECT *" in a production program if you don't process the SQLDA yourself. Tom
    125,585 pointsBadges:
    report
  • Nutangujar
    I just replaced select * by the actual field names howver I still see the same problem.. OENNOCD still splits ... I debug the program lately, while debugging OENNOCD = 'BLACK' however when it is displayed in the subfile it is 'B' 'LACK' ...again the same unwanted spaces introduced..
    895 pointsBadges:
    report
  • CharlieBrowne
    I looked at all the code and I agree that it must in the fetch routine. When you debug, are you looking at the field when you are doing the write to the subfile? I would debug after the write and look at the values in these fields: OENAUDT6 OENAUTM4 OENAUUID10 OENDSEQ OENNOCD OENFQCD OENOCCU OENPRCD8 OENCOMT OENPFST
    41,380 pointsBadges:
    report
  • Nutangujar
    yes the values of those variables are same before writing and after writing to the subfile...Those are the correct values fetched from the DB. ...only subfile when displays shows wrong values....
    895 pointsBadges:
    report
  • TomLiotta
    Ensure that you signed off and back on after recompiling. Ensure that any job using the program has ended and restarted after recompiling. That helps with getting activation groups cleaned up, QTEMP cleaned up, QRPLOBJ out of the picture, etc. Then, recreate the problem. Use DSPJOB when the problem is on the screen to ensure the job's library list, call stack library names and open files llibrary names are all as expected. Clearly there's something involved that we're not able to see because we're remote. Tom
    125,585 pointsBadges:
    report
  • Nutangujar
    thanks all...I'm still fighting ....I'm debugging the calling program one level up now...looks like i'll see something there.....
    895 pointsBadges:
    report
  • philpl1jb
    So having eliminated the input process and the program the error must be (drum roll) the display file I suspect that ... 1. That field OENFQCD was previously 1 char 2. That the previous version of the display file is somewhere on your computer -- use DSPOBJD *ALLUSR/xxxx *file <-- substitue your display file name for the xxxx 3. That the display file has level check .. *NO 4. That if you did the dspjob for the job that is displaying the bad data, as Tom suggested, you would discover in opt 14 that the display file is from the location of the older version. How this works - you load the buffer for the display file based on the new spec You pass this buffer to the old display file. If level check is *Yes it would send an error but since it isn't it lays the new buffer into the old record structure and everything is pushed to the left 4 spaces or so and since they are only output the fields are untouched in the RPG program. Phil
    49,850 pointsBadges:
    report
  • Nutangujar
    Thanks all.....it worked...the buffer was being sent to the old file during runtime..which had character lenghth 1 Thanks very much for all your help!!!!! :-)
    895 pointsBadges:
    report
  • TomLiotta
    Check to make sure you are using the correct DSPF. That's from CharlieBrowne's original "Answer". As discussion went on, it started becoming clear that "I checked all that thrice" might have been a slight exaggeration. At some point, ya' gotta verify the fundamentals, eh? Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following