CL Program Parameters Help

CL Program Parameters Help

Post by tgast » Fri, 09 Oct 1998 04:00:00



I am new with CL Programming and found some errors could not figure out.  MY
test CLP is just like this:

PGM PARM(&DECFLD)
DCL VAR(&DECFLD) TYPE(*DEC) LEN(10)
CHGDTAARA DTAARA(NUMTEST) VALUE(&DECFLD)
ENDPGM

I just call the program above as
CALL PGM1(500)

It gives me an error.  Sorry I cannot give the exact error since I am at
home right now.

Why am I getting this error?   I tried changing the variable to be *CHAR
instead of *DEC and it worked.   I am using V4R1 with I think March 1998
PTF's.

If someone can email the response to

I would appreciate it.

Thanks.

 
 
 

CL Program Parameters Help

Post by Jim Wels » Fri, 09 Oct 1998 04:00:00


declaring your numeric parm as TYPE(*DEC) LEN(15 5) will allow you to call
the program from the command line without putting the value in Hex format.

I've worked with alot of code that use this method of parm passing....although
not real
pretty when done properly you get alot less surprises with the dreaded infamous
decimal data error...

The problem you describe is very common on the 400...i suggest you find out all
you
can about it and then implement the best coding standard within your shop. Once
you
understand what is happening and why you can eliminate these errors and save
yourself
and your users alot of grief...

There are those that continue to do it wrong over and over and again...

don't be one of those...your in the right place for answers

try the phrase "decimal data error" in deja news and see what turns up...I know
it's been
discussed more than once.

Best Wishes


> I am new with CL Programming and found some errors could not figure out.  MY
> test CLP is just like this:

> PGM PARM(&DECFLD)
> DCL VAR(&DECFLD) TYPE(*DEC) LEN(10)
> CHGDTAARA DTAARA(NUMTEST) VALUE(&DECFLD)
> ENDPGM

> I just call the program above as
> CALL PGM1(500)

> It gives me an error.  Sorry I cannot give the exact error since I am at
> home right now.

> Why am I getting this error?   I tried changing the variable to be *CHAR
> instead of *DEC and it worked.   I am using V4R1 with I think March 1998
> PTF's.

> If someone can email the response to

> I would appreciate it.

> Thanks.

--
Jim
http://www.netcom.com/~jimwelsh/welcome/welcome.html


 
 
 

CL Program Parameters Help

Post by Orangta » Sat, 10 Oct 1998 04:00:00


When you call a CL with a *DEC parameter..the value must be in hex
format....or..you change change the parameter to *CHAR..Ron

 
 
 

CL Program Parameters Help

Post by Tim » Sat, 10 Oct 1998 04:00:00


Your program is expecting your parameter in packed decimal format with 10
digits. by default the command line interpreter passes numeric literals as
packed decimal with 15 digits and 5 decimal places.

You have several options available to you
1. Pass a literal hex value. The command interpreter passes the value into
program without modification.
    CALL PGM1 (X'00000000500F')
    Packed decimals require an extra hex digit for the sign. The last hex
digit must be x'F' for positive numbers and x'D' for negative numbers.
Furthermore, hex literals must have an even number of digits. Therefore, in
the literal you see 11 digits plus 1 for the sign.

2. Change your program to expec TYPE(*DEC) LEN(15 5). then on the command
line you can simply type
    CALL PGM1 (500)

3. You can write a command definition and compile it. See the CL programmers
guide for instructions on this


>I am new with CL Programming and found some errors could not figure out.
MY
>test CLP is just like this:

>PGM PARM(&DECFLD)
>DCL VAR(&DECFLD) TYPE(*DEC) LEN(10)
>CHGDTAARA DTAARA(NUMTEST) VALUE(&DECFLD)
>ENDPGM

>I just call the program above as
>CALL PGM1(500)

>It gives me an error.  Sorry I cannot give the exact error since I am at
>home right now.

>Why am I getting this error?   I tried changing the variable to be *CHAR
>instead of *DEC and it worked.   I am using V4R1 with I think March 1998
>PTF's.

>If someone can email the response to

>I would appreciate it.

>Thanks.

 
 
 

CL Program Parameters Help

Post by use » Sat, 10 Oct 1998 04:00:00


That *DEC(15 5) bug(?) has been in CL since _at least_ V3R0M5.  Hard to
believe IBM lets it exists without a good reason.  Anyone know what that
reason might be?

Regards,
Richard

> I am new with CL Programming and found some errors could not figure out.  MY
> test CLP is just like this:

> PGM PARM(&DECFLD)
> DCL VAR(&DECFLD) TYPE(*DEC) LEN(10)
> CHGDTAARA DTAARA(NUMTEST) VALUE(&DECFLD)
> ENDPGM

> I just call the program above as
> CALL PGM1(500)

> It gives me an error.  Sorry I cannot give the exact error since I am at
> home right now.

> Why am I getting this error?   I tried changing the variable to be *CHAR
> instead of *DEC and it worked.   I am using V4R1 with I think March 1998
> PTF's.

> If someone can email the response to

> I would appreciate it.

> Thanks.

 
 
 

CL Program Parameters Help

Post by Gary Guthri » Sat, 10 Oct 1998 04:00:00


Quote:> That *DEC(15 5) bug(?) has been in CL since _at least_ V3R0M5.  Hard to
> believe IBM lets it exists without a good reason.  Anyone know what that
> reason might be?

CL passes parameters by reference, i.e., a pointer containing the address of the space
allocated to the parameter. The space is allocated by the CALLING program, not the called
program. Because this allocation occurs in the calling program (in this case the command
interpreter program), some default attributes (length, etc.) must be established by the
calling program.

For numeric parameters, it's 15,5 for character it's 32 bytes.

Gary Guthrie
Editor, The RPG Source
Technical Editor, NEWS/400 magazine

 
 
 

CL Program Parameters Help

Post by Jim Wels » Sun, 11 Oct 1998 04:00:00


Well stated Gary.

I enjoy your RPG newsletter, however I am still really too busy fighting fires with PC's and
NT
problems, as well converting PRMS to the y2k compliant version...it's really discouraging to
be in
this position...everyone clamoring for Windows and more windows...sometimes it seems I am
the only one in the company who is gung-ho AS/400.

Ever since pc's have inflitrated all the shops I get less and less time to learn AS/400, when
I do get the time i'm too damned burned out to get into it.

I think IBM's Universal Database plans sound very interesting, since I know alot of DB2/400
I could use type of skill on other platforms...like one I could afford at home to work on.

Do you think we will see the day when we have a version of OS/400 on our desktops ? : )

Since I'm having so much trouble even learning more RPG...i'm still totally clueless about
Java...

I've looked at it, downloaded the IDE and went through the first exercise...pointing and
clicking and following the instructions is easy enough but Java code looks total greek to
me...may as well
be Chinese or something far as i'm concerned.

I thought programming was supposed to evolve over the years and keep getting easier.

I think i'll stick with RPG...this business isn't even fun anymore like it used to be
anyway...
you work your *off, you get no respect, and your surrounded by Bill Gate's followers.

Hey IBM ???? Are you listening ?????

Flip burgers ?

Well let me tell ya, flipping burgers might be a helluva lot more fun than i'm having right
now.

IBM has done virtually nothing to improve upon CL programming since OPNQRYF was added
about 10 years ago.

CL is a great language! Anyone ever hear of it ? NO, just us AS/400 geeks...

Well it may be too late to save the 400 at my present shop since the Corporate IT Director
has already forced Winframe on us, then it will be Metaframe and possibly JD Edwards running
on NT...

Well I noticed all the News/400 guru's saying how bad we needed NT in all those issues i've
paid for over the years...

I've seen NT, I work with NT, ALL I HEAR IS NT

Then you have the managers who think the AS/400 is *when the company hasn't put any new
software on it in 10 years...

I think I need to get a job at $BANK$ : ) I just happen to like manufacturing, so much more
interesting than debits and credits.

I think things may turn around...but things will certainly never be same.

C++, Java, HTML, CGI, Perl, Rexx...

Hey I'm a CL, DDS, RPG guy, not a rocket scientist!

what's with all the semi colons, brackets and paraenthesis in Java ?

THAT's progress ?????

Coulda fooled me...

You guys think i'm worried ?

Listen, I've been doing this stuff for like 12 years in about 5 or 6 different shops...in
that time
I have worked with ONE fabulous AS/400 programmer, and, and, and...

AND THAT'S ABOUT IT

I've been wading through spaghetti my entire career, it's gotten to the point where if you
can spell RPG your my best friend...so your a spaghetti coder...well, okay..at least your
doing it on OS/400...that's a plus...lol

or is it

Wer'e doomed...

Y2K is coming, I have software to make compliant, NT is down but that's okay...gives the
users a chance to take a break and chatter about the latest .wav file

Okay...so this is all my fault...i should have chosen some better companies to work for...

Yes that is what I should have done...well maybe it's not too late...

Green screens are so cool though...I will miss them...besides not being a rocket scientist I
am
no artist either...damn...well maybe there will be some cool *default colors ..lol

What about it IBM ? Can we have some cool *default colors to go with that Java ?

Anyway, thanks for the newsletter Gary...your a genious! Feature some pop-up windows and
presentation type stuff and I'll try and make some time to study it and get it on the box.

Just keep me going for another 10 years or so, so I can get the hell out of this business.

The truth is ... I hate Computers

LOL


> > That *DEC(15 5) bug(?) has been in CL since _at least_ V3R0M5.  Hard to
> > believe IBM lets it exists without a good reason.  Anyone know what that
> > reason might be?

> CL passes parameters by reference, i.e., a pointer containing the address of the space
> allocated to the parameter. The space is allocated by the CALLING program, not the called
> program. Because this allocation occurs in the calling program (in this case the command
> interpreter program), some default attributes (length, etc.) must be established by the
> calling program.

> For numeric parameters, it's 15,5 for character it's 32 bytes.

> Gary Guthrie
> Editor, The RPG Source
> Technical Editor, NEWS/400 magazine

--
Jim W
http://www.veryComputer.com/~jimwelsh/welcome/welcome.html

 
 
 

CL Program Parameters Help

Post by Nicholas Bridg » Sun, 11 Oct 1998 04:00:00


I would like to add something to this discussion, not a big omission but
still...

The data area type should match the variable type.

If the data area is *CHAR format, then just use *CHAR for the variable.

Only if the data area is *DEC do you need to worry about (15 5) etc.

Regards,

Nick B.


> I am new with CL Programming and found some errors could not figure out.  MY
> test CLP is just like this:

> PGM PARM(&DECFLD)
> DCL VAR(&DECFLD) TYPE(*DEC) LEN(10)
> CHGDTAARA DTAARA(NUMTEST) VALUE(&DECFLD)
> ENDPGM

> I just call the program above as
> CALL PGM1(500)

> It gives me an error.  Sorry I cannot give the exact error since I am at
> home right now.

> Why am I getting this error?   I tried changing the variable to be *CHAR
> instead of *DEC and it worked.   I am using V4R1 with I think March 1998
> PTF's.

> If someone can email the response to

> I would appreciate it.

> Thanks.

 
 
 

CL Program Parameters Help

Post by Richard Rensh » Tue, 20 Oct 1998 04:00:00


Gary:
        Thanks.  That makes sense.  I suppose I should stop calling it bug
and start calling it a idiosyncrasy.  I would have guessed *CHAR would
have been 255, though.

Regards,
Richard


Quote:> > That *DEC(15 5) bug(?) has been in CL since _at least_ V3R0M5.  Hard to
> > believe IBM lets it exists without a good reason.  Anyone know what that
> > reason might be?

> CL passes parameters by reference, i.e., a pointer containing the address of the space
> allocated to the parameter. The space is allocated by the CALLING program, not the called
> program. Because this allocation occurs in the calling program (in this case the command
> interpreter program), some default attributes (length, etc.) must be established by the
> calling program.

> For numeric parameters, it's 15,5 for character it's 32 bytes.

> Gary Guthrie
> Editor, The RPG Source
> Technical Editor, NEWS/400 magazine

 
 
 

1. Passing Parameters to a CL Program - HELP

Hi All,

   One of the programmers that I support stump me today.  He asked me,
"how do you pass quotation marks to a CL program?"  Is this possible?  

Any help would be greatly appreciated.
eR

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
* The end crowns all;               *
* And that old common arbitrator,   *
* Time, will one day end it.        *
*-*-*-*-*-*-*-*-*-*-*-*-*-*-BS*-*-*-*

2. Symmetry axis

3. Problem passing parameters to CL program

4. Backup to an IBM tape backup

5. Java, CL -how do you exit our of qshell from a CL Program

6. Lasat

7. Need a little help with CL program for AS/400

8. Adrian Gschwend: "I've Been Misquoted!"

9. cl program help? anyone?

10. Help with reading a Physical File 2 times in a CL program

11. Help please; Override database file in cl program.

12. message interception for RPG program in a CL program

13. Invoking a Java program from a CL or RPG program.