#15 Large PeopleCode files get truncated

v1.0 (example)
Erik H
0.53 (1)

I'm using Decode PeopleCode 0.53 and for no apparent reason large PeopleCode files aren't getting decoded completely. Looking at two examples, I have one Record Field PeopleCode that is 4776 lines long, but only 4234 lines were decoded (542 lines missing) and an Application Package PeopleCode that is 4311 lines long, but only 3751 lines were decoded (560 lines missing).

While looking at this I thought that maybe it was very large files, but I also found one that is 1385 lines long, but only 1213 lines got decoded (172 lines missing). So there is something happening that is not taking the last bit of the files.

(I know that the PeopleCode isn't stored in the database according to line numbers, but I thought I would include the line information to give you a sense of how much code was missing.)


  • Jonathan Rehm

    Jonathan Rehm - 2013-07-25

    I am having this issue as well on PeopleSoft Tools 8.53.

  • Erik H

    Erik H - 2013-07-25

    Cramill, are you also using tools >= 8.52? The program does not actually decode the bytecode if it can access the new table 'PSPCMTXT', since that (read-only) table contains the plain-text PeopleCode.

    You may want to add a line
    in the properties file, which will make it ignore this table.

    If that solves the problem, perhaps you can try and find out if the entire pcode text is available in PSPCMTXT (large code segments will be split up in several rows with increasing SEQNR). Thanks.

  • Jonathan Rehm

    Jonathan Rehm - 2013-07-25

    That AlwaysDecode=true did the trick for me. I looked at the PSPCMTXT record for one of the offending PeopleCode objects and it definitely truncates the code. I took the output with AlwaysDecode=true and the output of the table (obtained via SQL Developer) and used WinMerge to compare them and ~250 lines of code were missing from the PSPCMTXT one.

    I don't remember seeing AlwaysDecode=true in the recent documentation, but I think it'd be a great idea to highlight it in an FAQ or Troubleshooting section, because I bet we won't be the only ones to run into this over time.

    Thanks for an amazing project! I was distraught with it not working because it's imperative to our workflow.

  • Erik H

    Erik H - 2013-07-25

    Did not think anybody would actually need the AlwaysDecode parameter - I created it for testing purposes.

    It's annoying that the PSPCMTXT table is not reliable. Even though it made my project's name a bit of a misnomer, I liked it because it provides the exact formatting that is also used in AppDesigner.

    I don't really have time for this now, but perhaps one of you can complain bitterly to Oracle...

  • Cramill

    Cramill - 2013-08-02

    Setting AlwaysDecode=true fixed it for me as well. Thanks!

  • Erik H

    Erik H - 2014-04-18

    Fixed in 0.54. Now using separate queries on PSPCMTXT and PSPCMPROG (the latter table is still required to get the LASTUPDDTTM and LASTUPDOPRID values) - previously, used a join on these tables do get all the info in one go, but apparently the two tables can be split into a different number of rows (SEQNOs). Beats me why they split up these rows, anyway - they are CLOB / BLOB fields...

  • Erik H

    Erik H - 2014-04-18
    • status: open --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks