|
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 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
