|
> -----Original Message----- > From: rpg400-l-admin@midrange.com > [mailto:rpg400-l-admin@midrange.com]On > Behalf Of rpg400-l-request@midrange.com > Sent: Wednesday, December 11, 2002 3:23 PM > To: rpg400-l@midrange.com > Subject: RPG400-L digest, Vol 1 #1223 - 10 msgs > > > Send RPG400-L mailing list submissions to > rpg400-l@midrange.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or, via email, send a message with subject or body 'help' to > rpg400-l-request@midrange.com > > You can reach the person managing the list at > rpg400-l-admin@midrange.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPG400-L digest..." > > > Today's Topics: > > 1. RE: Software audit (was: Can an RPG module call another RPG > modul e?) (Evan Harris) > 2. Day of the week (Bob Cozzi) > 3. RE: Day of the week (rob@dekko.com) > 4. RE: Can an RPG module call another RPG module? (rob@dekko.com) > 5. RE: Can an RPG module call another RPG module? (rob@dekko.com) > 6. CLLE and date type parameter in RPGLE subprocedure > (Reggie Acosta) > 7. RE: Can an RPG module call another RPG module? (rob@dekko.com) > 8. RE: CLLE and date type parameter in RPGLE subprocedure > (Buck Calabro) > 9. Re: API QIMGCVTI (Scott Klement) (Scott Klement) > > --__--__-- > > Message: 1 > Date: Thu, 12 Dec 2002 08:08:59 +1300 > To: rpg400-l@midrange.com > From: Evan Harris <spanner@ihug.co.nz> > Subject: RE: Software audit (was: Can an RPG module call another RPG > modul e?) > Reply-To: rpg400-l@midrange.com > > Hi Buck > > I once had a short contract with a bank which included change control > duties. Part of the promotion process was to move the source > to production > and create all production objects from the source on the production > machine. Source was stored in designated libraries. > > This was intended to ensure that any production object had current and > available source and that the source matched the object; this > was audited > regularly. It was also intended to ensure that the > compilation and creation > process was performed in a way that maintained security. > > Since they were a few releases behind I have no idea how they > would handle > service programs and the like. > > There were lots of other things we did, but it was a pretty involved > tedious detailed process :) > > Regards > Evan Harris > > >Alan wrote: > > > > >The point I was trying to make was, if the modules etc are > > >NEVER migrated to the production area, there is no way to > > >satisfy an audit. (Been there, done that) If you can prove > > >that the modules etc were migrated to the production area, and > > >that when they were required again, they had been migrated > > >back or accessed from the production area, the auditors will > > >be satisfied (been there done that) > > > >There might be issues revolving around how the banking industry does > >software audits, but we never ship any part of the > development environment > >to our production machines (customers.) That means no > source, modules, > >binding directories, prototype /COPYs, binder language: > nothing. Just *PGM > >and *SRVPGM objects. > > > >We still haven't found a machine-enforced guaranteed chain > of evidence that > >THIS source is in THAT object, although manual signatures in > binder source > >help with service programs. Although that can be forged > easily enough. > >Matching the source change date/times AND the *SRVPGM > signatures AND the > >file signatures provides a degree of security that the > executable is pretty > >much what you think it is, always presuming that you have a > reference object > >to compare against. > > --buck > > > --__--__-- > > Message: 2 > From: "Bob Cozzi" <cozzi@rpgiv.com> > To: <rpg400-l@midrange.com>, <rpgiv@yahoogroups.com> > Subject: Day of the week > Date: Wed, 11 Dec 2002 15:17:52 -0600 > Reply-To: rpg400-l@midrange.com > > > I've implemented the Zeller Congruence in RPG IV. > I attempted to do both RPG IV on OS/400 V4R4 and later and > for V5R1 and > later. > That is what the /IF DEFINED(*V5R1M0) is doing. > > Here's the code and thanks to Rick for pointing out the > website that had > the equation. > > There are two procedures: DayOfWeek which returns the day of the week > using the IBM-supplied API. It work good and should be used in all > cases. The second procedure is named GetDayEx() and returns the day of > the week using the Zeller Congruence > > Bob Cozzi > www.rpgworld.com > > > These are the prototypes, stored in the /COPY named DATES in QCPYSRC. > /IF NOT DEFINED(RTK_DATES) > /DEFINE RTK_DATES > D DayOfWeek PR 10I 0 > D InDate D Const DATFMT(*ISO) > > D GetDayEx PR 10I 0 > D InDate D Const DATFMT(*ISO) > > D GetEndOfMonth PR D DATFMT(*ISO) > D InDate D Const DATFMT(*ISO) > /ENDIF > > This is the source for the two procedures DayOfWeek() and GetDateEx(), > since I simply updated the source from my RPG ToolKit it has some > additional comments and other stuff (like copyrights) in there. > Hope this helps > > Bob Cozzi > > H NOMAIN BNDDIR('QC2LE') > H Copyright('2002 by Robert Cozzi, Jr. All Rights Reserved.') > > ****************************************************************** > ** (c) Copyright 2002 by Robert Cozzi, Jr. > ** Portions Copyright 1988 by Robert Cozzi, Jr. > ** All rights reserved. > ** Part of the RPG ToolKit for OS/400 www.rpgiv.com/toolkit > > ****************************************************************** > /COPY QCPYSRC,dates > > .....P*rocName+++++++..B...................Functions++++++++++ > ++++++++++ > +++++++ > P DayOfWeek B EXPORT > ** Procedure interface for DayOfWeek function > .....D*ame+++++++++++EUDS.......Length+TDc.Functions++++++++++ > ++++++++++ > +++++++ > D DayOfWeek PI 10I 0 > D InputDate D CONST DATFMT(*ISO) > ** Base date is based on calendar changed date > D BaseDate S D Static INZ(D'1582-10-14') > D nDayOfWeek S 10I 0 > D nDays S 10I 0 > .....C*Rn01Factor1+++++++OpCode(ex)Factor2+++++++Result+++++++ > +Len++DcHi > LoEq > C TEST(E) InputDate > C If %ERROR > C Return -1 > C Endif > C InputDate SubDur BaseDate nDays:*DAYS > > C CALLB 'CEEDYWK' > C Parm nDays > C Parm nDayofWeek > > C return nDayOfWeek > P DayOfWeek E > > P GetDayEx B Export > > D GetDayEx PI 10I 0 > D InDate D Const DATFMT(*ISO) > > D nPart1 S 10I 0 > D nDay S 10I 0 > D nMonth S 10I 0 > D nYear S 10I 0 > D nMod S 10I 0 > D nDayOfWeek S 10I 0 > > C Extrct InDate:*D nDay > C Extrct InDate:*M nMonth > C Extrct InDate:*Y nYear > C if nMonth < 3 > C eval nMonth = nMonth + 12 > C eval nYear = nYear - 1 > C endif > /IF DEFINED(*V5R1M0) > C Eval nDayOfWeek = > %Rem(%div((13*nMonth+3):5) + > C nDay + nYear + > %div(nYear:4) > - > C %div(nYear/100) + > %div(nYear:400)) > C : 7) > C/ELSE > C eval nPart1 = %Int((13*nMonth+3)/5) + > C nDay + nYear + > %int(nYear/4) > - > C %int(nYear/100) + > %int(nYear/400) > C nPart1 DIV 7 nMod > C MVR nDayOfWeek > C/ENDIF > ** The date we return is ones-based and Sunday oriented (1=Sun, > 2=Mon, etc.) > ** whereas the calculation produces a zero-based and > Monday-oriented > ** (e.g., 0=Mon, 1=Tues, 3=Wed, etc. 7=Sun). > ** We need to convert the day from the Mon=0-based value to the > Sun=1 based value. > C If nDayOfWeek > 5 > C Eval nDayOfWeek = nDayOfWeek - 5 > C else > C eval nDayOfWeek + 2 > C endif > C return nDayOfWeek > PGetDayEx E > > > -----Original Message----- > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com] > On Behalf Of rick.pezzimenti@denso.com.au > Sent: Tuesday, December 10, 2002 9:28 PM > To: rpg400-l@midrange.com > Subject: Re: Day of the week > > > This is a multipart message in MIME format. > -- > -- > [ Picked text/plain from multipart/alternative ] > Not sure if it has been mentioned here, but chap by the name of Zeller > had a formula for finding the day of the week for any date. > Do a search > on google for "zeller's congruence" and it should turn up quite a few > results. Alternatively, have a look here > > http://www.sciencenet.org.uk/database/Maths/Original/m00030d.html > > I believe it only works on dates between 1562-3999, which should be ok > for your purpose I would think! > > > > --__--__-- > > Message: 3 > To: rpg400-l@midrange.com > Subject: RE: Day of the week > From: rob@dekko.com > Date: Wed, 11 Dec 2002 11:43:26 -0500 > Reply-To: rpg400-l@midrange.com > > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > One minor point that seemed to generate a flood of emails in the years > past. There is an ISO standard on what day of the week is > the first. I > forget what it is. Check the archives. I don't know if my > routine is ISO > standard. > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > --__--__-- > > Message: 4 > To: rpg400-l@midrange.com > Subject: RE: Can an RPG module call another RPG module? > From: rob@dekko.com > Date: Wed, 11 Dec 2002 11:41:02 -0500 > Reply-To: rpg400-l@midrange.com > > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > Excellent example. Best way to compare our binding to the C > programmer > new to the 400. > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > > > > "Joe Pluta" <joepluta@PlutaBrothers.com> > Sent by: rpg400-l-admin@midrange.com > 12/11/2002 11:41 AM > Please respond to rpg400-l > > To: <rpg400-l@midrange.com> > cc: > Fax to: > Subject: RE: Can an RPG module call another RPG module? > > > > From: alan shore > > > > Sorry, I sent the last e-mail before I was ready to. > > The point I was trying to make was, if the modules etc are NEVER > > migrated to the production area, there is no way to satisfy an > > audit. (Been there, done that) If you can prove that the modules > > etc were migrated to the production area, and that when they were > > required again, they had been migrated back or accessed from the > > production area, the auditors will be satisfied (been there > done that) > > Do your auditors require source on the production machine? A > module is no > more relevant to the program object than is the source. In a > completely > secured environment, you would do neither compiles nor binds on the > production machine, so you'd need neither the source nor the > modules for > auditing purposes. > > Think of it the same way you would a C program. You create a > C program by > linking together a bunch of .obj files. In a production environment, > you'd > never see those .obj files. > > My .02 > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) > mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > --__--__-- > > Message: 5 > To: rpg400-l@midrange.com > Subject: RE: Can an RPG module call another RPG module? > From: rob@dekko.com > Date: Wed, 11 Dec 2002 16:23:46 -0500 > Reply-To: rpg400-l@midrange.com > > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > Sounds like they make banks go through a bunch of bunk. > > Alan, If the source is NEVER on the production machine in the first > place, how can they possibly be using the wrong version of the source? > Let's say you don't even have the compiler loaded on the production > machine. Which we often don't. The only reason that the > compiler is on > our largest machine is because of one software package that > generates RPG > on the fly for flexible reporting. > > Do you also have to keep a list of vendor programs that have > no source, in > the case of vendor purchased packages? How do the auditors > approve these? > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > > > > "alan shore" <SHOREA@dime.com> > Sent by: rpg400-l-admin@midrange.com > 12/11/2002 12:34 PM > Please respond to rpg400-l > > To: <rpg400-l@midrange.com> > cc: > Fax to: > Subject: RE: Can an RPG module call another RPG module? > > > Our auditors (internal and external) require ALL pieces > (sources, modules > etc) to be migrated to the Production region, irrespective of > the platform > that is being used. Mainframe, HP UNIX, AS/400 etc. > There has been TOO many cases where a developer has wanted > source XYZ to > be modified due to a request from a user. Lo and behold XYZ > is out there > in development, and rather than take the extra time to copy from the > production area, has used the one in development, only to > find out AFTER > making the necessary changes that the source that ended up > being used had > been change by some one else for some other reason. The > result was then a > waste of time. The source would then have to be copied from > the production > region and the changes re-applied to the correct version. > > >>> "Joe Pluta" <joepluta@PlutaBrothers.com> 12/11/02 11:41AM >>> > > From: alan shore > > > > Sorry, I sent the last e-mail before I was ready to. > > The point I was trying to make was, if the modules etc are NEVER > > migrated to the production area, there is no way to satisfy an > > audit. (Been there, done that) If you can prove that the modules > > etc were migrated to the production area, and that when they were > > required again, they had been migrated back or accessed from the > > production area, the auditors will be satisfied (been there > done that) > > Do your auditors require source on the production machine? A > module is no > more relevant to the program object than is the source. In a > completely > secured environment, you would do neither compiles nor binds on the > production machine, so you'd need neither the source nor the > modules for > auditing purposes. > > Think of it the same way you would a C program. You create a > C program by > linking together a bunch of .obj files. In a production environment, > you'd > never see those .obj files. > > My .02 > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) > mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > --__--__-- > > Message: 6 > From: "Reggie Acosta" <racosta@brownjordan.com> > To: <rpg400-l@midrange.com> > Subject: CLLE and date type parameter in RPGLE subprocedure > Date: Wed, 11 Dec 2002 14:30:39 -0800 > Reply-To: rpg400-l@midrange.com > > This is a multi-part message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > When subprocedure RtvWeekOfYear in service program is called > from CLLE, date > data type parameter DateIn contains garbage. Is the only way > to make this > work is to change the parameter to character data type? > > Thanks... > > DCL VAR(&ENDDATE) TYPE(*CHAR) LEN(10) VALUE('2002-12-07') > DCL VAR(&weekOfYear) TYPE(*DEC) LEN(6 0) > > CALLPRC PRC(rtvWeekOfYear) PARM(&ENDDATE) + > RTNVAL(&weekOfYear) > > > .....DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++ > ++++++++++++++ > ++++ > D RtvWeekOfYear PR 10I 0 > D D Value > > ..... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 > ...+... 8 > P RtvWeekOfYear B Export > D RtvWeekOfYear PI 10I 0 > D DateIn D Value > ... > P RtvWeekOfYear E > > Reggie Acosta > Sr. Programmer/Analyst > Brown Jordan Company > 9860 Gidley St. > El Monte, CA 91734 > Email: mailto:racosta@brownjordan.com > http://www.brownjordan.com > > -- > > > --__--__-- > > Message: 7 > To: rpg400-l@midrange.com > Subject: RE: Can an RPG module call another RPG module? > From: rob@dekko.com > Date: Wed, 11 Dec 2002 16:28:34 -0500 > Reply-To: rpg400-l@midrange.com > > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > How would that buy you a higher level of security? Don't, > traditionally, > more people have access to your production machine than your > development > machine? Even if you secure your source libraries do you secure your > compiler commands? I could load source on our machine, > compile it, and > never have had used a 5250 session so the bunk about 'menu > security' and > 'restricting access to the command line' is meaningless. > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > > > > "alan shore" <SHOREA@dime.com> > Sent by: rpg400-l-admin@midrange.com > 12/11/2002 12:42 PM > Please respond to rpg400-l > > To: <rpg400-l@midrange.com> > cc: > Fax to: > Subject: RE: Can an RPG module call another RPG module? > > > Get different auditors. I'm hoping thats tongue in cheek. Our external > auditors are federally controlled (Office of Thrift > Supervision), with the > power of removing the system/application there and then, with > no ifs and > buts. The fact that a person has to take the extra time to copy the > production source or whatever from the production area and moans about > this just leaves me shaking my head in disbelief. It buys you a higher > level of security. > >>> <rob@dekko.com> 12/11/02 11:39AM >>> > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > Get different auditors. I don't know how keeping the > source/modules/binding language/etc on the production machine buys you > anything. > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > > > > "alan shore" <SHOREA@dime.com> > Sent by: rpg400-l-admin@midrange.com > 12/11/2002 10:51 AM > Please respond to rpg400-l > > To: <rpg400-l@midrange.com> > cc: > Fax to: > Subject: RE: Can an RPG module call another RPG module? > > > Sorry, I sent the last e-mail before I was ready to. > The point I was trying to make was, if the modules etc are > NEVER migrated > to the production area, there is no way to satisfy an audit. > (Been there, > done that) If you can prove that the modules etc were migrated to the > production area, and that when they were required again, they had been > migrated back or accessed from the production area, the > auditors will be > satisfied (been there done that) > > >>> <rob@dekko.com> 12/11/02 09:49AM >>> > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > The same way you can if they are all on the same system. > > How can you assure audit that the source has went through the > testing and > QC phase on your development machine if your source, modules, > etc are all > on your production machine? > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > > > > "alan shore" <SHOREA@dime.com> > Sent by: rpg400-l-admin@midrange.com > 12/11/2002 09:39 AM > Please respond to rpg400-l > > To: <rpg400-l@midrange.com> > cc: > Fax to: > Subject: RE: Can an RPG module call another RPG module? > > > Interesting point, however, if everything used to create the > final product > (source, modules etc) are NOT migrated to the production > environment, how > can you satisfy and/or assure any audit (both internal and/or > external) > that any subsequent binds using those modules are in fact using > unchanged/unhacked versions. > > >>> "Bryan Yates" <byates@co.collin.tx.us> 12/10/02 05:11PM >>> > Yes Dan, a module or a group of modules are bound together to create a > program or service program object. It is this object that > the system uses > when running the program, not the modules > > -----Original Message----- > From: Dan [mailto:dbcerpg@yahoo.com] > Sent: Tuesday, December 10, 2002 4:14 PM > To: rpg400-l@midrange.com > Subject: RE: Can an RPG module call another RPG module? > > > Is this a true statement? "The only use for a *MODULE object is to be > able to create a program object, nothing more, nothing less. > > - Dan > > --- rob@dekko.com wrote: > > This is a multipart message in MIME format. > > -- > > [ Picked text/plain from multipart/alternative ] > > That module thing does take some getting used to. A just > told a gent > > here > > that you do not need to move your *MODULE or *BNDDIR to the > > production > > machine. Just the *SRVPGM. > > > > Rob Berendt > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) > mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > --__--__-- > > Message: 8 > From: Buck Calabro <Buck.Calabro@commsoft.net> > To: rpg400-l@midrange.com > Subject: RE: CLLE and date type parameter in RPGLE subprocedure > Date: Wed, 11 Dec 2002 17:47:49 -0500 > Reply-To: rpg400-l@midrange.com > > CL has no date data type. If you must use CL, you'll have to > use a data > type that CL has. Which one is up to you. > --buck > > --__--__-- > > Message: 9 > Date: Wed, 11 Dec 2002 17:21:29 -0600 (CST) > From: Scott Klement <klemscot@klements.com> > To: rpg400-l@midrange.com > cc: B.Quindt@ZAPF-BAYREUTH.DE > Subject: Re: API QIMGCVTI (Scott Klement) > Reply-To: rpg400-l@midrange.com > > > Hello Burkhard, > > On Wed, 11 Dec 2002 B.Quindt@ZAPF-BAYREUTH.DE wrote: > > > > thank you for your help, I took the API - Parameter from > QSYSINC/QRPGLESRC > > QIMGAPII > > > > I want to Convert a TIFF Streamfile in IFS to a AFP > Streamfile in IFS > > > > Okay, so the problem isn't the format of the data structures, > but rather > that they're not initialized with proper values. > > > > Here is the Source-Code > > > > CRT-Options - CRTMOD then CRTPGM with BNDSRVPGM(QSYS/QIMGCIMG) > > > > You can't post attachments to the mailing list. Since you copied me > directly, I received your source code, but the other people > on the mailing > list did not. > > The error that this program generates is MCH0601. The text for this > is "Space offset (number) or teraspace offset (number) is > outside limit > for object (job name)". > > The reason you're getting this error is because you didn't initialize > the 'bytes provided' value in the QUSEC (error code) data structure. > When you don't explicitly intiialize a data structure, the entire > structure gets set to blanks. > > Therefore, because the hex value for a blank is x'40', the 'bytes > provided' was set to x'40404040', so the system thought that your > QUSEC structure was 1077952576 bytes long. When it tried to write > an error message past the 15th byte of the structure (since in reality > it's only 15 bytes long) it signalled the space offset error. > > Simply setting QUSBPRV to the number 15 before calling the API > will allow you to get a more useful error message. > > Also, you might consider setting QUSBPRV to 0, which will cause the > error to be signalled to your program stack rather than returning it > in a variable in your program. > > Another suggestion I'd like to make, just to make the code easier to > read, is that you should use *ALLx'00' instead of variables like > 'Q0016' and 'Q0032'. > > For example, instead of this: > C MOVE Q0032 QIMAH > You'd code this: > C eval QIMAH = *ALLx'00' > > There are some other issues with you code, such as a 'paper size > conflict', but once you've fixed the QUSBPRV variable, the system will > tell you about the problems, so you can fix them yourself. > > Good Luck! > > > > > --__--__-- > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) > digest list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > End of RPG400-L Digest
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
