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



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


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.