× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Bob, I just ran what you sent and it did fail , but with the message I 
expected, "The target for a numeric operation is too small to hold the result". 
 Not the intermediate result message Steve got.  I am running on V5R3 but I 
believe the intermediate message was around in V5R2 but I could be wrong.

Mike 

-----Original Message-----
From: Bob Cozzi [mailto:cozzi@xxxxxxxxx]
Sent: Friday, February 04, 2005 10:20 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Level 40 field size problem


Sure, just try it.

D testfld   S     3P 0

C        Z-ADD 999999    testFld      // Will work

C        eval  testFld = 999999      // Will fail

-Bob


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Mike Tobey
Sent: Friday, February 04, 2005 10:11 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Level 40 field size problem

I'm surprised you received that error message, I thought that the
intermediate version of the result too small to hold result message was only
issued for complex expressions a = ((b * 100) + c).  I have never
encountered it on a simple expression a = b.

Mike

-----Original Message-----
From: Steve Moland [mailto:Steve@xxxxxxxxxxx]
Sent: Friday, February 04, 2005 8:34 AM
To: 'rpg400-l@xxxxxxxxxxxx'
Subject: Level 40 field size problem


An RPG program which has been running since dirt was still uneroded rock and
on thousands of systems both CISC and RISC under every OS level there is,
does not like to run on V5R2 after a system was switched to level 40
security. It had been running fine the day before the switch.

The failure makes no sense to me.

"An intermediate result is not large enough to contain the result"

The line of code which fails is:

Eval      YPageTo = 999999

The receiver field is defined as follows

 d YPageTo                59     64S 0 

It is not the first line of executable code in the program and any obvious
authority problems would have probably blown up the program much earlier in
executing code due to failures in user space creation or work file creation
code which calls APIs and a bunch of subprogram calls. Debugging shows no
authority related problems and in fact there are no other failures or
warnings at all.

Though it shouldn't make any difference, this program is running from within
a CL program called via an FTP remote command from a VB program on a PC
client. 

Steve Moland
Access Paths Inc
12 Parmenter Rd Unit-C4
Londonderry NH 03053
603.845.0190 Ext 2
steve@xxxxxxxxxxx  - personal
support@xxxxxxxxxxx - tech support


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of rpg400-l-request@xxxxxxxxxxxx
Sent: Friday, February 04, 2005 12:12 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG4rpg400-l@xxxxxxxxxxxxxxxx Digest, Vol 4, Issue 159


Send RPG400-L mailing list submissions to
        rpg400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
        rpg400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
        rpg400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific than
"Re: Contents of RPG400-L digest..."


Today's Topics:

   1. RE: Prototyped Procedures (James Rich)
   2. RE: Prototyped Procedures (Joe Pluta)
   3. RE: Fully qualified data structures (Tim Kredlo)
   4. RE: Prototyped Procedures (Joe Lee)
   5. Re: Prototyped Procedures (Paul Morgan)
   6. RE: Prototyped Procedures (Joe Pluta)
   7. RE: Prototyped Procedures (Scott Klement)
   8. API for copying and printing spoolfiles (AnetteK@xxxxxxxxxx)


----------------------------------------------------------------------

message: 1
date: Thu, 3 Feb 2005 15:16:53 -0700 (MST)
from: James Rich <james@xxxxxxxxxxx>
subject: RE: Prototyped Procedures

On Thu, 3 Feb 2005, Bob Cozzi wrote:

> IF you add BASED to the original field, no storage is allocated for 
> it. For example:
>
> D MyDate_T    DS               BASED(ptr_Nowhere)
> D  Year                   2S0
> D  Month                  2S0
> D  Day                    2S0
>
> D Mydates      DS               LikeDS(MyDate_T)

Huh.  I wouldn't have thought of this in a million years.  I assume 
ptr_Nowhere is defined somewhere?  Not necessarily assigned a value, but 
defined?  Cool technique, though.  Even if it does feel a little gimicky. 
I notice Scott is using the same idea.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw


------------------------------

message: 2
date: Thu, 3 Feb 2005 16:45:50 -0600
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: Prototyped Procedures

> From: James Rich
> 
> Huh.  I wouldn't have thought of this in a million years.  I assume 
> ptr_Nowhere is defined somewhere?

Actually, this is a little "magic" on the part of the compiler folks. You
CAN specify the variable elsewhere as a pointer (type "*"), but if you
don't, the compiler will generate one for you.  Typically you use the latter
when you want to initialize it.

D FkeyDS      DS               BASED(pFkeyDS)
D  Fkey                    N   DIM(24)
DpFkeyDS      S            *   inz(%addr(*INKA))

Ta da.  Now Fkey(5) is the same as *INKE.

Joe



------------------------------

message: 3
date: Thu, 3 Feb 2005 14:46:02 -0800
from: "Tim Kredlo" <TKredlo@xxxxxxxxxxxxxxxx>
subject: RE: Fully qualified data structures

Charles,

Thank you very much!

It was the name 'Out' that was causing the problem.
Changed it and program compiled.
I never write to data areas and forgot (or maybe even never knew) that 'OUT'
was an op code.

The DS with the same name as the other DS subfield was not an issue. The
'Qualified'  handled that OK.

Again, thanks for the help.

Tim Kredlo
Exterior Wood, Inc.

Ps: In my 'real' program QYer is named 'QtyPerYear', 'QMon' is named
'QtyPerMonth', and QDay is named 'QtyForDay' Thought I would shorten it up
for the list to make the lack of typos more apparent.






------------------------------

message: 4
date: Thu, 03 Feb 2005 15:20:41 -0800
from: "Joe Lee" <LeeJD@xxxxxx>
subject: RE: Prototyped Procedures

Obviously you can use 'N' or '*', etc... and yes an RPG programmer "should"
know what those are. However, how many times have I seen articles or
discussions regarding the differences between 'I' and 'B' and should it be
2B or 4B or 5I or 10I. I do find an advantage to
like(int) or like(pointer), they are easier for me to read. Isn't that the
goal of many of the newer RPG enhancements, there is no "need" for free
format, fixed works just fine, however free is much easier to read (at least
for me). The indicators for the various opcodes work fine also, but I much
prefer to use the new bifs, according to your logic, since they do the same
thing there is no reason to use the bifs, especially since %eof(FILENAME) is
much longer than *IN90, and any RPG programmer "should" know what that
means.

I also use Like and LikeDS to define new data types, though ideally I would
like to have a keyword that specifically indicated that a field or data
structure was only being used as a definition. This could prevent the data
type definitions from accidently being used, and prevent the space for them
from being wasted. Though in most cases the waste of space is negligible,
and if you are really worried about it the based trick will prevent even
that. What I don't like about the based trick is that it doesn't tell me if
the variable is a data type definition, or if it is actually going to be
used as a based variable. Similarly without some kind of "standard", which
will vary from shop to shop, or comments in the code, and how many people
put as many of those in as they should, there is no way to tell the
programmer that "addressDS" or "address_T" or "address*" is a data type not
an actual variable. 

As for specifying the length of a variable, I was only suggesting it for the
compiler defined types. Since it would be extremely annoying to have only
some of the basic data types available from built in Like definitions. It
would be a lot like the current issues where for some things you must mix
free and fixed format code. (I will not comment on whether or not you need
to do many of those things.) I don't see any reason for user defined data
types to be able to have a length defined, though I am sure that someone
will come up with one.

Joe Lee

>>> rpg400-l@xxxxxxxxxxxxxxxx 02/03/2005 13:52:20 >>>


> I do that also, though what I'd really like is for the basic
"types",
> such as Indicator/Boolean, Pointer, Int, LongInt, etc... to be
included
> somehow in the compiler, so that I don't have to /COPY them into
every
> program.

They are.  Indicator is called 'N', Pointer is '*', Int is 'I'... 
That's 
the way RPG works, it uses a single character to represent the type.

I don't feel that you gain anything at all by typing the following:

      D myVar           s                   like(int)

instead of the following:

      D myVar           s              10I 0

You're really saying the exact same thing. An RPG programmer knows (or

SHOULD) what "10I 0" means. He reads the line of text as "10 digit 
integer". You explicitly using the word "int" doesn't really add anything 
to it... in either case he knows it's an integer.  The programmer is 
reading the same thing, it's just a slightly different way of saying it.

You know what I mean?  Six of one, half a dozen of the other.

On the other hand, you can use likeds() and like() to create your OWN data 
types. Instead of just assigning "english" names to RPG's data types...

For example, your business may have a standard for how an address is 
defined. In the USA, you might have two lines that represent the street

address, then a city name, state abbreviation and zip code.

So, you might define that in a /COPY file like this:

      D Address_T       ds                  qualified
      D                                     based(TEMPLATE)
      D   Line1                       40A
      D   Line2                       40A
      D   City                        13A
      D   State                        2A
      D   ZipCode                      9A

When you want to use it, you'd create your own copy like this:

      D myAddr          ds                  likeds(Address_T)

That's the same way that you'd use a typedef in C.  In C you'd have 
something like the following:

      struct _Address {
         char line1[41];
         char line2[41];
         char city[14];
         char state[3];
         char zipcode[10];
      };
      typedef struct _Address Address_T;

(the lengths are one byte longer to save space for a x'00' at the end) When
you wanted to use it, you'd code:

      Address_T myAddr;

So, it's not really that different from what you can do in RPG.

> Packed, zoned, and character might be problematic, but maybe they 
> could be handled with something like: like(packed:30:9), or 
> like(char:32), or even like(varchar:1024) for a varying length
character
> field.

For what you're trying to do (make English names for RPG data types) your 
idea of specifying a length makes sense -- but, again, if you were allowed 
to do that, it'd be the "six of one, half dozen of the other" thing again. 
Whether you code "32A" instead of like(char:32) doesn't really buy you

anything except a program that looks slightly more like the English 
language.

On the other hand, if I were writing a service program, and that program 
accepted parameters of a fixed type... maybe Address, as in the previous 
example...  I wouldn't WANT you to be able to specify a length. I would

want your address to exactly match the one in the service program so that 
they'd be compatible with one another.

So, I put my ADDRESS_T data structure in a /copy member.  You code 
LIKEDS(Address_T) to make your own copy of it... pass it as a parameter to 
a procedure in my srvpgm (the prototype would also specify LIKEDS, and

would also be in the /copy member) and then we'd be working with the same 
thing.

-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx 
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l 
or email: RPG400-L-request@xxxxxxxxxxxx 
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



------------------------------

message: 5
date: Thu, 3 Feb 2005 18:25:11 -0500
from: "Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>
subject: Re: Prototyped Procedures

Joe,

This is a dangerous piece of code.  It's relying on the memory layout of the
indicators by the RPG compiler that isn't defined by the RPG language spec.
You're assuming that *INKE is five bytes past the address of *INKA which
might not always be the case.   The RPG spec makes no mention of *INKA being
stored in memory before *INKE.  Maybe the compiler in V5R4 will do something
different with these variables and break your code.  Doing this with
%Addr(*IN) is ok because *IN is defined by the compiler to always be an
array of all the indicators from 01 to 99.

D pINKE                       * Inz(%Addr(*INKE))
D F5Refresh                   N Based(pINKE)

Will work and isn't dangerous.  Now F5Refresh is an alias for *INKE.

Paul

BTW, Mr Cozzi doesn't like the use of the *INKx indicators.  Renaming the
*INKx indicators with a more meaningful name solves the problem with these
indicators without resorting to a key code field is some system specific
data structure.  Use of a renamed *INKx variable is portable but the data
structure layout isn't.

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333

"Joe Pluta"

> Actually, this is a little "magic" on the part of the compiler folks. 
> You CAN specify the variable elsewhere as a pointer (type "*"), but if 
> you don't, the compiler will generate one for you.  Typically you use 
> the latter when you want to initialize it.
>
> D FkeyDS      DS               BASED(pFkeyDS)
> D  Fkey                    N   DIM(24)
> DpFkeyDS      S            *   inz(%addr(*INKA))
>
> Ta da.  Now Fkey(5) is the same as *INKE.
>
> Joe





------------------------------

message: 6
date: Thu, 3 Feb 2005 18:07:31 -0600
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: Prototyped Procedures

> From: Paul Morgan
> 
> Joe,
> 
> This is a dangerous piece of code.  It's relying on the memory layout
of
> the indicators by the RPG compiler that isn't defined by the RPG 
> language spec.

Paul, I asked the compiler team (specifically Barbra Morris) if they ever
planned on changing the layout of the indicator area and they said no, that
if they were to change that a lot of other things would have to change as
well.

Technically, there's really nothing in the spec that says the 99
conditioning indicators are in a row either, is there?  Yet people sometimes
count on that. 

Anyway, it may be dangerous, but I'll live with it.

Joe



------------------------------

message: 7
date: Thu, 3 Feb 2005 18:20:03 -0600 (CST)
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: RE: Prototyped Procedures


> I also use Like and LikeDS to define new data types, though ideally I 
> would like to have a keyword that specifically indicated that a field 
> or data structure was only being used as a definition. This could 
> prevent the data type definitions from accidently being used, and 
> prevent the space for them from being wasted.

I agree.  Though, I think BASED(TEMPLATE) works pretty well for that, I'd 
much rather see something that's specifically designed for it.

> Though in most cases the waste of space is negligible, and if you are
> really worried about it the based trick will prevent even that. What I 
> don't like about the based trick is that it doesn't tell me if the 
> variable is a data type definition, or if it is actually going to be 
> used as a based variable.

That's why I use a name like 'TEMPLATE' for the pointer. Or, if my fingers 
aren't too tired, I might do something like:

           BASED(TEMPLATE_ONLY)

I don't think it's very likely that someone will think that memory is 
being allocated to a variable named TEMPLATE_ONLY...  Though, I do agree 
that something that's specifically designed for this would be a little 
nicer.

> Similarly without some kind of "standard", which will vary from shop 
> to
> shop, or comments in the code, and how many people put as many of those 
> in as they should, there is no way to tell the programmer that 
> "addressDS" or "address_T" or "address*" is a data type not an actual 
> variable.

I agree.  Though the '_T' convention is very commonly used in C on all 
platforms.  For example 'size_t' or 'in_addr_t'.  Many compilers and/or 
operating systems come with #include files for C (like /copy files for 
RPG) that contain that suffix meaning "data type"

Although it's not a standard in RPG, it'd be really nice if it were :)

But, yeah, again I like the idea of having a keyword that's specifically 
designed for this -- but I don't think the current method is a 
show stopper.  It works well and is a lot better than forcing the caller 
to define his own definitions in every program...


> As for specifying the length of a variable, I was only suggesting it 
> for the compiler defined types. Since it would be extremely annoying 
> to have only some of the basic data types available from built in Like 
> definitions.

Maybe when they create free format D-specs, they'll allow us to specify 
names like 'char' or 'int' or 'varying' instead of the letters?

Of course, at some point you say to yourself, "Why don't I just code it in 
C in the first place?"



------------------------------

message: 8
date: Fri, 4 Feb 2005 07:10:05 +0200
from: AnetteK@xxxxxxxxxx
subject: API for copying and printing spoolfiles


I have created a number of user spaces and copied various spool files and 
their attributes into them and created a library containing these files :
User Space                                 Size
SB000001    *USRSPC   USRSPC                 61440 
SB000002    *USRSPC   USRSPC                 32768 
SB000003    *USRSPC   USRSPC                 32768 
SB000004    *USRSPC   USRSPC                 20480 


I then have a program that runs that converts these user spaces back into 
spoolfiles :
c                   callp(e)  QSPCRTSP(wkFile: dsSA: dsEC) 
c                   if        %error 
c                   eval      wkSaveArea = wkSplfArea 
c                   callp     QMHRSNEM(*blanks: dsEC: dsRS: %size(dsRS): 
c                                   'RSNM0100': *NULL: 0)  
c                   endif  
c                   callp(e)  QSPPUTSP(wkFile: peUsrSpc: dsEC)  
c                   if        %error  
c                   eval      wkSaveArea = wkSplfArea  
c                   callp     QMHRSNEM(*blanks: dsEC: dsRS: %size(dsRS):   

c                                   'RSNM0100': *NULL: 0)  
c                   endif  
c                   callp(e)  QSPCLOSP(wkFile: dsEC)  
c                   if        %error  
c                   eval      wkSaveArea = wkSplfArea  
c                   callp     QMHRSNEM(*blanks: dsEC: dsRS: %size(dsRS):   

c                                   'RSNM0100': *NULL: 0)  
c                   endif  
c                   eval      wkSaveArea = wkSplfArea  
c                   eval      *inlr = *on  

The problem is that no spool files are created by the QSPCRTSP, QSPPUTSP 
API's. I have run a debug and the parms passed to the API's definitely 
contain data when passing or returning. I am missing something VERY 
elementary and I am afraid I do not know what. Any advice would be 
appreciated.

PS - These are 2 programs from the News400 backup spool files offering.

Thanks and regards

Anette

IMPORTANT NOTICE: 
This email message and any attachments are confidential and intended solely
for the addressee. If you have received this message in error, please notify
us immediately via email: complaints@xxxxxxxxxx 
Any unauthorized use, alteration or dissemination is prohibited. 
Bell Equipment accepts no claim whatsoever for any direct, indirect or
consequential loss arising from any communication whether directed,
misdirected or intercepted.

This email is subject to important restrictions and qualifications subject
to the disclaimers published on our website (www.bellequipment.com). 
The disclaimer is deemed to form part of the content of this email in terms
of Section 11 of the Electronic Communication and Transactions Act,25 of
2002. If you cannot access the Disclaimer, please obtain a copy thereof from
us by sending an email to helpdesk@xxxxxxxxxx

------------------------------

-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) digest list To
post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



End of RPG400-L Digest, Vol 4, Issue 159
****************************************
-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.