ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Convert dec to int

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Convert dec to int

    I have a parm that needs to be dec, this then needs to be converted to int. I have tried many iterations of %bin but the conversion always gets corrupted. Is this even possible?
    Thanks

  • #2
    Re: Convert dec to int

    Hi kswanson0522:

    Is this what you are looking for or am I not understanding your question

    myint = %int(mydec) ;
    mydec = %dec(myint) ;

    Best of Luck
    GLS
    The problem with quotes on the internet is that it is hard to verify their authenticity.....Abraham Lincoln

    Comment


    • #3
      Re: Convert dec to int

      Sorry let me be a little more clear I have the following
      DCL VAR(&APPLEN) TYPE(*DEC) LEN(4)
      DCL VAR(&APPLEN2) TYPE(*INT) LEN(4)

      I need APPLEN2 to have the value of APPLEN, I have another process that uses APPLEN and needs to have it be *DEC, but the end process needs to have it in INT. How do i convert APPLEN to APPLEN2 ?
      Thanks

      Comment


      • #4
        Re: Convert dec to int

        Code:
        chgvar var(&applen2) value(&applen)

        Comment


        • #5
          Re: Convert dec to int

          Scott thanks for the reply, so I actually have 2 variables I need in the same program. I needed to get the length of a string passed into the CL and found a sample on the web with this
          RTVVARLEN
          PGM PARM(&STRING &LEN)
          DCL VAR(&STRING) TYPE(*CHAR) LEN(2000)
          DCL VAR(&LEN) TYPE(*DEC) LEN(4 0)
          CHGVAR VAR(&LEN) VALUE(%BIN(&STRING 1 2))
          ENDPGM

          This is then called in my main CL
          DCL VAR(&APPLEN) TYPE(*DEC) LEN(4)
          DCL VAR(&LABLEN) TYPE(*DEC) LEN(4)
          DCL VAR(&APPLEN2) TYPE(*INT) LEN(4)
          DCL VAR(&LABLEN2) TYPE(*INT) LEN(4)

          RTVVARLEN STRING(&APPID) LEN(&APPLEN)
          RTVVARLEN STRING(&LABEL) LEN(&LABLEN)
          CHGVAR VAR(&APPLEN2) VALUE(&APPLEN)
          CHGVAR VAR(&LABLEN2) VALUE(&LABLEN)

          I found that APPLEN2 comes out perfect but LABLEN2 does not. Below is the dump output

          &APPLEN *DEC 4 0 20
          &APPLEN2 *INT 4 15 0000000F
          &LABLEN *DEC 4 0 18
          &LABLEN2 *INT 4 -1009269006 C3D7C6F2

          Not sure why APPLEN2 works but not LABLEN2, in debug view both APPLEN2 and LABLEN2 look to be good, the final call looks like this

          CALLPRC PRC('******') PARM((&APPID2) +
          (&APPLEN2) (&FORMAT) (&LABEL2) (&LABLEN2) +
          (&RETURN))
          I can't give out the procedure I'm calling as it's restricted API.
          so both APPLEN2 and LABLEN2 have values, (20 and 18) but the dump as I said has corrupted data for LABLEN2.
          Thanks

          Comment


          • #6
            Re: Convert dec to int

            Can you post the strings you are using to get your results? Hex would be good.

            Comment


            • #7
              Re: Convert dec to int

              &APPID *CHAR 256 'QIBM_QTMF_FTP_CLIENT ' D8C9C2D46DD8E3D4C66DC6E3D76DC3D3C9C5D5E3
              &LABEL *CHAR 256 'GeoTrust Global CA ' C78596E399A4A2A340C7939682819340C3C1

              Comment


              • #8
                Re: Convert dec to int

                Your RTVVARLEN program makes the assumption that you are receiving an RPG VARYING variable, or SQL VARCHAR, etc, type variable as a parameter. This is different from a regular fixed-length character field.

                In VARYING/VARCHAR, the first two bytes of the field contain the length, and the remaining part of the field contains the data. so you can use %BIN() on the first two bytes to extract the length in that case.

                But a regualr character string does not have the length in the first two bytes, it just has the string data. You said that you are getting hex C3D7C6F2 (which is 4 bytes...???) that implies that the first 4 chars of your string are 'CPF2' (looks like the start of a MSGID)... this doesn't appear to be a length that you're receiving, here... it looks like a regular character string...

                Comment


                • #9
                  Re: Convert dec to int

                  Okay, now that you've posted the strings, I don't see how this could ever work...???

                  The only thing that MIGHT explain it is if you are using a *CMD interface with *VARY defined.

                  Comment


                  • #10
                    Re: Convert dec to int

                    I am using the code from here

                    Just yesterday, I was trying to determine the length of the value of a CL variable, so your tip today using the MSGDTA trick was helpful. I was thinking that IBM had added %TRIM and %LEN to the list of CL built-in functions (BIFs) that exist in recent releases, but I guess I was imagining

                    Comment


                    • #11
                      Re: Convert dec to int

                      Look here.
                      Philippe

                      Comment


                      • #12
                        Re: Convert dec to int

                        You said "both APPLEN2 and LABLEN2 have values, (20 and 18) ". Does that mean you got the correct LABLEN2 at some point, but it later got changed to the strange value? Is LABLEN2 correct just before you call the API and then it gets corrupted during the API call?

                        Scott is right that the bad value looks like the beginning of a message ID (CPF2...). So if &LABLEN2 is is fine before the API and it's getting corrupted during the API call, I would guess that there's probably something wrong with the way you're passing the parameters. Maybe the parameters are out of order, or maybe the parameter lengths aren't correct, or maybe you don't have enough parameters, and it's finding a pointer to &LABLEN2 when it's looking for a missing parameter, or ... well, there's lots of ways you can get corruption if you pass parameters incorrectly.

                        Comment


                        • #13
                          Re: Convert dec to int

                          This is just odd, I tred mercury's suggestion and the same thing happens. I put the program in debug mode, when I step through it everything looks fine even the call to the API at the end all values are holding, when I view the data for APPLEN2 and LABLEN2 they have correct values (20 and 18) which is the length of the strings I'm passing, but after the call and at the ENGPGM I view the data LABELN gets changed to the corrupt data. So I think Scott is correct in that the last call is incorrect, the information i have for the API variable I'm passing for LABLEN2 is as follows
                          INPUT; BINARY(4)
                          The length must be a value from 1 to 1024.
                          When I remove all the code for determining the length of the fields and just pass them in manually with the call to the program it works just fine, I am really perplexed on this one.

                          Comment


                          • #14
                            Re: Convert dec to int

                            I wonder if the last parameter in the API (just before the LABELN2) is the issue, the parameter is defined as
                            Error code I/O Char(*)
                            I'm not sure what to do with this since it's defined as I/O all the other API's I work with are Return Code output.

                            Comment


                            • #15
                              Re: Convert dec to int

                              Originally posted by kswanson0522 View Post
                              I found that APPLEN2 comes out perfect but LABLEN2 does not. Below is the dump output

                              &APPLEN *DEC 4 0 20
                              &APPLEN2 *INT 4 15 0000000F
                              &LABLEN *DEC 4 0 18
                              &LABLEN2 *INT 4 -1009269006 C3D7C6F2
                              In order for that to make sense to us, the first thing we need to know is when those values are accessed in debug. If they are accessed immediately after the CHGVAR for VAR(&LABLEN2), it will have a very different meaning from immediately after the CALLPRC for PRC('******').

                              So, are you showing us a dump after a failure of the API is called? If so, then the "value" in any variable might be unrelated to the conversion from *DEC to *INT. Memory corruption after a CALL or a CALLPRC failure can change lots of stuff.
                              Tom

                              There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

                              Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

                              Comment

                              Working...
                              X