|
I wonder, if the statement line number in error corresponds with the statement line number in the source. A recomplie of the programme and a view of the compile listing will show the real culprit. The shown code looks correct, and as it is an old programme, I do not think it has anything to do with EVAL. Regards, Carel Teijgeler *********** REPLY SEPARATOR *********** On 4-2-05 at 10:54 Mike Tobey wrote: >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. > > >-- >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 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.
midrange.com
