|
midrange.com
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
If you want to pass a varying length piece of data then define the parameter
as VARYING and your problems should be over (and you won't need the %Trim in
the subproc). I should point out though that using VALUE for a large field
like this is not exacly going to be a stellar performer. There are better
ways of doing it.
Anything that big should really be passed by reference. You could pass the
original as OPTIONS(*STRING) which would result in null termination which is
what most of the C routines want anyway - that way you don't need the %Addr
either - just pass the pointer directly. You would however need to pass the
length of the string as an additional parm - you could work it out in the
subproc but it's hardly worth the effort. PS. None of this is tested -
just compiled - just like in real life <g>
The first way would look like:
d IFS_prt pi
d hFile like(int) value
d Text 32766a value varying
d NbrWritten s like(int)
c eval NbrWritten = api_write(
c hFile:
c %addr(Text):
c %len(Text))
and the second method like so:
d IFS_prt pi
d hFile like(int) value
d pText * options(*String) value
d Len 10i 0 value
d NbrWritten s like(int)
c eval NbrWritten = api_write(
c hFile:
c pText:
c Len)
Jon Paris
Partner400
> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
> Behalf Of rpg400-l-request@midrange.com
> Sent: Thursday, December 13, 2001 9:19 AM
> To: rpg400-l@midrange.com
> Subject: RPG400-L digest, Vol 1 #268 - 13 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: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*LSTDBG) (bmorris@ca.ibm.com)
> 2. RE: Prototype for a command parameter. (bmorris@ca.ibm.com)
> 3. Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*LSTDBG) (L. Maartens)
> 4. RE: Prototype for a command parameter. (Bob Cozzi (RPGIV))
> 5. RE: Prototype for a command parameter. (Scott Klement)
> 6. Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*LSTDBG) (bill.reger@convergys.com)
> 7. Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*L (Mike Naughton)
> 8. Re: Big complex parameter. (Joep Beckeringh)
> 9. RE: Big complex parameter. (Bob Cozzi (RPGIV))
> 10. Procedure parameter with VALUE option (Peter Dow)
> 11. Re: Problem with SBMJOB (RPG III) (hrishikesh kotwal)
> 12. Re: Problem with SBMJOB (RPG III) (Peter Colpaert)
> 13. Re: Problem with SBMJOB (RPG III) (Mike.Collins@syan.co.uk)
>
> --__--__--
>
> Message: 1
> From: bmorris@ca.ibm.com
> Subject: Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*LSTDBG)
> To: rpg400-l@midrange.com
> Date: Wed, 12 Dec 2001 15:15:07 -0500
> Reply-To: rpg400-l@midrange.com
>
>
> >From: "L. Maartens" <l.maartens@chello.nl>
> >Date: Wed, 12 Dec 2001 16:27:22 +0100
> >
> >Can someone tell me how to determine if a (RPG) program object has been
> >compiled with OPTION(*SRCDBG) or OPTION(*LSTDBG) ?
> >
> >As a software company i want to avoid to distribute my systems
> with easily
> >retrieveable sources.
>
> Loek, you don't have to worry about *SRCDBG, since that requires the
> source to be available. You can see if a program was compiled with
> *LSTDBG using DMPOBJ. Near the bottom of the dump listing (look on the
> right hand side) you can see the whole compiler listing.
>
> Barbara Morris
>
>
> --__--__--
>
> Message: 2
> From: bmorris@ca.ibm.com
> Subject: RE: Prototype for a command parameter.
> To: rpg400-l@midrange.com
> Date: Wed, 12 Dec 2001 15:15:35 -0500
> Reply-To: rpg400-l@midrange.com
>
>
> >From: "Bob Cozzi \(RPGIV\)" <cozzi@rpgiv.com>
> >Date: Wed, 12 Dec 2001 10:35:12 -0600
> > ...
> >To solve this, I've created a /COPY that includes all these data type,
> >and I've named them INT1, INT2, INT4, and INT8. And I've been using
> >LIKE(INT4) in my code. (Please tell me the LIKE'd fields are INT4 and
> >not packed!)
>
> Bob, the LIKE'd fields are INT4 and not packed. :)
>
> As long as you use LIKE (and not *LIKE DEFINE), your LIKE'd fields
> have the format of the original. With *LIKE DEFINE, it depends. (See
> your local RPG manual for all the gruesome details of how *LIKE DEFINE
> operates.)
>
> Barbara Morris
>
>
> --__--__--
>
> Message: 3
> From: "L. Maartens" <l.maartens@chello.nl>
> To: <rpg400-l@midrange.com>
> Subject: Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*LSTDBG)
> Date: Wed, 12 Dec 2001 21:33:41 +0100
> Reply-To: rpg400-l@midrange.com
>
> Barbara,
>
> Thanks for your reply.
>
> We mainly use *LSTDBG, due to the proliferation of /COPY members.
>
> I was hoping there would be some kind of API to retrieve this information
> from the program object. Forcing a DMPOBJ and subsequent inspection of the
> listing for each and any program we are to deliver to our
> customers, on the
> off-chance that we left a program with *LSTDBG within the suite to be
> expedited, is a bit tedious.
>
> However, if that is what it takes, then that is what we have to do.
>
> Loek.
>
>
>
> --__--__--
>
> Message: 4
> From: "Bob Cozzi \(RPGIV\)" <cozzi@rpgiv.com>
> To: <rpg400-l@midrange.com>
> Subject: RE: Prototype for a command parameter.
> Date: Wed, 12 Dec 2001 14:42:51 -0600
> Reply-To: rpg400-l@midrange.com
>
> Well, I knew that, and I've always work under that impression, but Jon
> Paris once said that that wasn't true in all cases, so I started to
> doubt myself.
> Thanks for bringing the truth back to light. :)
> Happy Holidays!
>
> Bob Cozzi
> cozzi@rpgiv.com
> Visit the new on-line iSeries Forums at: http://www.rpgiv.com/forum
>
> > -----Original Message-----
> > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
> On
> > Behalf Of bmorris@ca.ibm.com
> > Sent: Wednesday, December 12, 2001 2:16 PM
> > To: rpg400-l@midrange.com
> > Subject: RE: Prototype for a command parameter.
> >
> >
> > >From: "Bob Cozzi \(RPGIV\)" <cozzi@rpgiv.com>
> > >Date: Wed, 12 Dec 2001 10:35:12 -0600
> > > ...
> > >To solve this, I've created a /COPY that includes all these data
> type,
> > >and I've named them INT1, INT2, INT4, and INT8. And I've been using
> > >LIKE(INT4) in my code. (Please tell me the LIKE'd fields are INT4
> and
> > >not packed!)
> >
> > Bob, the LIKE'd fields are INT4 and not packed. :)
> >
> > As long as you use LIKE (and not *LIKE DEFINE), your LIKE'd fields
> > have the format of the original. With *LIKE DEFINE, it depends. (See
> > your local RPG manual for all the gruesome details of how *LIKE DEFINE
> > operates.)
> >
> > Barbara Morris
> >
> > _______________________________________________
> > 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
> Date: Wed, 12 Dec 2001 15:01:29 -0600 (CST)
> From: Scott Klement <klemscot@klements.com>
> To: rpg400-l@midrange.com
> Subject: RE: Prototype for a command parameter.
> Reply-To: rpg400-l@midrange.com
>
>
>
> On Wed, 12 Dec 2001 bmorris@ca.ibm.com wrote:
> >
> > >Oh, yes... I knew they added 8-bit integer fields, but I didn't realize
> > >that they continued to expand the (worthless) "B" data type to
> 8-bits as
> > >well.
> >
> > Scott, 2B 0 isn't an 8-bit integer. It's a 16-bit integer, like it
> > always was. 2B 0 isn't an expansion. It's been there "forever" in RPG
> > and DDS at least, and is only supported in ILE RPG for compatibility
> > reasons. (Even if I-binary had been introduced in V3R1, we'd have had
> > to keep B-binary.)
>
> Yes, I know that they've been around forever, because I used to use them
> in RPG III.
>
> Here's what I'm thinking of... in RPG III, I used to do something
> like this:
>
> IDSCVT DS
> I B 1 10DSBIN
> I 1 1 DSCHAR
> C*
> C MOVE SOMETHING DSCHAR
> C DSPLY DSBIN
> C*
> C MOVE *ON *INLR
>
> I couldn't do this because the compiler complains that "DSBIN" must be
> either 2 or 4 bytes long.
>
> So, I guess that's where my confusion came from. I understand now that
> the binary type has to be 2 or 4 bytes long, but you can define it as
> "1B 0" thru "9B 0" and the compiler will just not use the extra decimal
> digits.
>
> Thanks again for the clarification.
>
>
>
> --__--__--
>
> Message: 6
> From: bill.reger@convergys.com
> Subject: Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*LSTDBG)
> To: rpg400-l@midrange.com
> Date: Wed, 12 Dec 2001 16:04:32 -0500
> Reply-To: rpg400-l@midrange.com
>
>
> Barbara and others,
>
> Correct me if I'm wrong but won't removing observability before packaging
> the deliverable solve Loek issue? For example:
>
> CHGPGM PGM(Library/*ALL) RMVOBS(*ALL)
>
> Bill
>
> --
>
> NOTICE: The information contained in this electronic mail transmission is
> intended by Convergys Corporation for the use of the named individual or
> entity to which it is directed and may contain information that is
> privileged or otherwise confidential. If you have received this
> electronic
> mail transmission in error, please delete it from your system without
> copying or forwarding it, and notify the sender of the error by
> reply email
> or by telephone (collect), so that the sender's address records can be
> corrected.
>
>
>
> --__--__--
>
> Message: 7
> Date: Wed, 12 Dec 2001 16:09:08 -0500
> Subject: Re: How to see if a RPG program was compiled with
> option(*SRCDBG) or option(*L
> To: rpg400-l@midrange.com
> From: "Mike Naughton" <mnaughton@juddwire.com>
> Reply-To: rpg400-l@midrange.com
>
> Loek,
>
> Just a thought, but you could certainly automate the DMPOBJ process. I
> don't know of any "scan spool file" command (though I wouldn't be
> surprised if someone has written a utility to do this), but I would guess
> you could at least copy the spool files to data files (or members of a
> data file) and then somehow scan the data files lookng for some pattern
> that would indicate embedded code.
>
> It would probably take a little effort to get it working right, but once
> you did so you'd have your own utility that you could use over and over,
> and from what you say it sounds as if it would pay for itself pretty
> quickly.
>
> IMHO, _anything_ to avoid scanning a lot of spool files by hand. . . . :-)
>
> Or (on a completely different tack), how about setting up an automated
> compile process that re-gens all your objects with no debug information?
> Then just run your code through this process as the last step before
> delivering it to the client. . . . (That way you'd also be sure that the
> objects were compiled from the latest source code. . .)
>
> rpg400-l@midrange.com writes:
> >Barbara,
> >
> >Thanks for your reply.
> >
> >We mainly use *LSTDBG, due to the proliferation of /COPY members.
> >
> >I was hoping there would be some kind of API to retrieve this information
> >from the program object. Forcing a DMPOBJ and subsequent
> inspection of the
> >listing for each and any program we are to deliver to our customers, on
> >the
> >off-chance that we left a program with *LSTDBG within the suite to be
> >expedited, is a bit tedious.
> >
> >However, if that is what it takes, then that is what we have to do.
> >
> >Loek.
>
>
> Mike Naughton
> Senior Programmer/Analyst
> Judd Wire, Inc.
> 124 Turnpike Road
> Turners Falls, MA 01376
> 413-863-4357 x444
> mnaughton@juddwire.com
>
>
> --__--__--
>
> Message: 8
> From: "Joep Beckeringh" <joep@beckeringh.myweb.nl>
> To: <RPG400-L@midrange.com>
> Subject: Re: Big complex parameter.
> Date: Wed, 12 Dec 2001 23:59:59 +0100
> Reply-To: rpg400-l@midrange.com
>
> Bob,
>
> Why use %SUBST? I'd make ElemItem a based structure. (I have a utility
> with a parameter like that. In the original version I processed it in CL.
> Brr.)
>
> Joep Beckeringh
> 45/15; love the cycle
>
> ----- Original Message -----
> From: "Bob Cozzi (RPGIV)" <cozzi@rpgiv.com>
> To: <rpg400-l@midrange.com>
> Sent: Wednesday, December 12, 2001 5:24 PM
> Subject: RE: Big complex parameter.
>
>
> > When you have a complex mixed list, it is passed something like this:
> >
> > D Elems DS 32766
> > D Count 5i0
> > D offset 5i 0 Dim(300)
> >
> >
> > The first COUNT field tells you how many elements were passed.
> > Then, an array of 2-byte binary integers are passed.
> > Each one contains an offset to an element on your list.
> > These offsets (if memory serves) are passed in backwards order,
> > last-first.
> > So if Offset(1) = 347, then in position 347+%size(count) would be the
> > first element on your list. You use %SUBST to access:
> >
> > %SUBST(Elems: offset(x)+%size(count): %size(target))
> >
> > Where TARGET is probably another data structure whose format matches the
> > element list. Element lists are passed as
> >
> > D ElemItem DS
> > D eCount 5I0 /* Not really needed */
> > D item1 10A
> > D item2 10A
> > D item3 10A
> >
> >
> > So each OFFSET would "point" to a bucket that contained an ELEMITEM set
> > of data.
> >
> > Now, all of this is from memory so check it out in that old issue of Q38
> > if you can get a copy from John Carr.
> >
> > Bob Cozzi
> > cozzi@rpgiv.com
>
>
>
>
>
>
> --__--__--
>
> Message: 9
> From: "Bob Cozzi \(RPGIV\)" <cozzi@rpgiv.com>
> To: <rpg400-l@midrange.com>
> Subject: RE: Big complex parameter.
> Date: Wed, 12 Dec 2001 18:40:52 -0600
> Reply-To: rpg400-l@midrange.com
>
> This guy is passing a list within a list that has a list in it.
> He is not passing a simple ELEM list which has the 2-byte binary prefix
> and then the 3 elements. Note the 3rd element in his example, has
> MAX(300) in addition the ELEM parent has MAX(300) specified.
>
> Bob Cozzi
> cozzi@rpgiv.com
> Visit the new on-line iSeries Forums at: http://www.rpgiv.com/forum
>
> > -----Original Message-----
> > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
> On
> > Behalf Of Joep Beckeringh
> > Sent: Wednesday, December 12, 2001 5:00 PM
> > To: RPG400-L@midrange.com
> > Subject: Re: Big complex parameter.
> >
> > Bob,
> >
> > Why use %SUBST? I'd make ElemItem a based structure. (I have a
> utility
> > with a parameter like that. In the original version I processed it in
> CL.
> > Brr.)
> >
> > Joep Beckeringh
> > 45/15; love the cycle
> >
> > ----- Original Message -----
> > From: "Bob Cozzi (RPGIV)" <cozzi@rpgiv.com>
> > To: <rpg400-l@midrange.com>
> > Sent: Wednesday, December 12, 2001 5:24 PM
> > Subject: RE: Big complex parameter.
> >
> >
> > > When you have a complex mixed list, it is passed something like
> this:
> > >
> > > D Elems DS 32766
> > > D Count 5i0
> > > D offset 5i 0 Dim(300)
> > >
> > >
> > > The first COUNT field tells you how many elements were passed.
> > > Then, an array of 2-byte binary integers are passed.
> > > Each one contains an offset to an element on your list.
> > > These offsets (if memory serves) are passed in backwards order,
> > > last-first.
> > > So if Offset(1) = 347, then in position 347+%size(count) would be
> the
> > > first element on your list. You use %SUBST to access:
> > >
> > > %SUBST(Elems: offset(x)+%size(count): %size(target))
> > >
> > > Where TARGET is probably another data structure whose format matches
> the
> > > element list. Element lists are passed as
> > >
> > > D ElemItem DS
> > > D eCount 5I0 /* Not really needed */
> > > D item1 10A
> > > D item2 10A
> > > D item3 10A
> > >
> > >
> > > So each OFFSET would "point" to a bucket that contained an ELEMITEM
> set
> > > of data.
> > >
> > > Now, all of this is from memory so check it out in that old issue of
> Q38
> > > if you can get a copy from John Carr.
> > >
> > > Bob Cozzi
> > > cozzi@rpgiv.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.
>
>
>
> --__--__--
>
> Message: 10
> From: "Peter Dow" <pcdow@yahoo.com>
> To: <RPG400-L@midrange.com>
> Subject: Procedure parameter with VALUE option
> Date: Wed, 12 Dec 2001 17:02:10 -0800
> Reply-To: rpg400-l@midrange.com
>
> Hi Everyone,
>
> I have an IFS service program with the following procedure:
>
> p IFS_prt b export
>
> d IFS_prt pi
> d hFile like(int) value
> d Text 32766a value
>
> d Data s 32766a
> d NbrWritten s like(int)
>
> c eval Data = %trimr(Text)
> c eval NbrWritten = api_write(
> c hFile:
> c %addr(Data):
> c %len(%trimr(Data)))
>
> p e
>
> And I use it in an RPGLE (V4R5) program like this:
>
> d CnvRec s 128a
>
> c eval CnvRec = 'GL CONVERSION ' + @TapeID + x'25'
> c callp IFS_prt(hCnvFile:CnvRec)
>
> Note the disparity in lengths of CnvRec and Text.
>
> The manual (Title: ILE RPG for AS/400 Reference; Document Number:
> SC09-2508-02) states that:
>
> "The rules for what can be passed as a value parameter to a
> called procedure
> are the same as the rules for what can be assigned using the EVAL
> operation.
> The parameter received by the procedure corresponds to the
> left-hand side of
> the expression; the passed parameter corresponds to the
> right-hand side. See
> "EVAL (Evaluate expression)" in topic 4.4.36 for more information."
>
> To me that sounds like it's effectively doing an EVAL TEXT = CNVREC in the
> above example. If that's true, then TEXT should be padded with
> blanks after
> the x'25'. Instead, starting at pos.1025, it has some junk, then
> repeats the
> value in CnvRec.
>
> So what's the real story with the VALUE option?
>
> tia,
> Peter Dow
> Dow Software Services, Inc.
> 909 425-0194 voice
> 909 425-0196 fax
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --__--__--
>
> Message: 11
> From: "hrishikesh kotwal" <hdkotwal@hotmail.com>
> To: rpg400-l@midrange.com
> Subject: Re: Problem with SBMJOB (RPG III)
> Date: Thu, 13 Dec 2001 12:56:51
> Reply-To: rpg400-l@midrange.com
>
> [ Converted text/html to text/plain ]
>
> Hi Mike,
>
> You wrote:
>
> >My preferred methodology would be to write to a work file in your data
>
> >library which has a primary key of job number. You write all the records
>
> >for the interactive job with its job number, then when you
> submit the batch
>
> >job, you pass the job number for the interactive job as a parameter, then
>
> >in the batch program only reads records for the passed job
> number. If more
>
> >than one job could be submitted from the interactive session for this
>
> >process, then you will need to have another unique identifier other than
>
> >just the job, but the principle remains the same.
>
> I adopted your suggested methodology to write a workfile in data
> library which
> has a primary key of job number. You had also suggested that if
> more than one
> job was to be submitted from the same interactive session for
> this process,
> then another unique identifier other than the job number, would
> be essential.
> I need to know which will be the other best unique identifier.
>
> Please advise, your suggestions have helped me see brighter days :-).
>
>
>
> Thanks & Regards,
>
> Hrishikesh Kotwal
>
> >From: Mike.Collins@syan.co.uk
> >Reply-To: rpg400-l@midrange.com
> >To: rpg400-l@midrange.com
> >Subject: Re: Problem with SBMJOB (RPG III)
> >Date: Mon, 12 Nov 2001 13:58:53 +0000
> >
> >
> >My preferred methodology would be to write to a work file in your data
> >library which has a primary key of job number. You write all the records
> >for the interactive job with its job number, then when you
> submit the batch
> >job, you pass the job number for the interactive job as a parameter, then
> >in the batch program only reads records for the passed job
> number. If more
> >than one job could be submitted from the interactive session for this
> >process, then you will need to have another unique identifier other than
> >just the job, but the principle remains the same.
> >
> >Mike
> >
> >_______________________________________________
> >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.
> >
>
> ------------------------------------------------------------------
> ------------
> MSN Photos is the easiest way to share and print your photos:
> Click Here[1]
>
> ===References:===
> 1. http://go.msn.com/bql/hmtag3_etl_EN.asp
>
>
> --__--__--
>
> Message: 12
> Subject: Re: Problem with SBMJOB (RPG III)
> To: rpg400-l@midrange.com
> From: "Peter Colpaert" <Peter.Colpaert@honda-eu.com>
> Date: Thu, 13 Dec 2001 14:02:17 +0100
> Reply-To: rpg400-l@midrange.com
>
>
> You could keep a counter in a data area, and add 1 to it every time you
> submit a job. Use the number as a parameter..
>
> This is what I use to create unique member names for work files ('M' + 9
> digits).
>
> When the highest value of 999999999 is reached, then the counter restarts
> at 1, because normally by that time there will be no more jobs pending of
> that long ago.
>
> Hope this helps.
>
> Peter Colpaert
> Application Developer
> Honda Europe NV
> ----------
> To know recursion, you must first know recursion.
> ----------
>
>
>
>
> "hrishikesh kotwal" <hdkotwal@hotmail.com>@midrange.com on 13/12/2001
> 13:56:51
>
> Please respond to rpg400-l@midrange.com
>
> Sent by: rpg400-l-admin@midrange.com
>
>
> To: rpg400-l@midrange.com
> cc:
>
> Subject: Re: Problem with SBMJOB (RPG III)
>
> I adopted your suggested methodology to write a workfile in data library
> which
> has a primary key of job number. You had also suggested that if more than
> one
> job was to be submitted from the same interactive session for
> this process,
> then another unique identifier other than the job number, would be
> essential.
> I need to know which will be the other best unique identifier.
>
> Please advise, your suggestions have helped me see brighter days :-).
>
>
>
> Thanks & Regards,
>
> Hrishikesh Kotwal
>
>
>
>
>
> --__--__--
>
> Message: 13
> Subject: Re: Problem with SBMJOB (RPG III)
> To: rpg400-l@midrange.com
> From: Mike.Collins@syan.co.uk
> Date: Thu, 13 Dec 2001 14:13:49 +0000
> Reply-To: rpg400-l@midrange.com
>
>
> Absolutely what I had in mind. Have a key of job number followed by such a
> counter.
>
>
>
>
> "Peter Colpaert" <Peter.Colpaert@honda-eu.com>@midrange.com on 13/12/2001
> 13:02:17
>
> Please respond to rpg400-l@midrange.com
>
> Sent by: rpg400-l-admin@midrange.com
>
>
> To: rpg400-l@midrange.com
> cc:
>
> Subject: Re: Problem with SBMJOB (RPG III)
>
>
>
> You could keep a counter in a data area, and add 1 to it every time you
> submit a job. Use the number as a parameter..
>
> This is what I use to create unique member names for work files ('M' + 9
> digits).
>
> When the highest value of 999999999 is reached, then the counter restarts
> at 1, because normally by that time there will be no more jobs pending of
> that long ago.
>
> Hope this helps.
>
> Peter Colpaert
> Application Developer
> Honda Europe NV
> ----------
> To know recursion, you must first know recursion.
> ----------
>
>
>
>
> "hrishikesh kotwal" <hdkotwal@hotmail.com>@midrange.com on 13/12/2001
> 13:56:51
>
> Please respond to rpg400-l@midrange.com
>
> Sent by: rpg400-l-admin@midrange.com
>
>
> To: rpg400-l@midrange.com
> cc:
>
> Subject: Re: Problem with SBMJOB (RPG III)
>
> I adopted your suggested methodology to write a workfile in data library
> which
> has a primary key of job number. You had also suggested that if more than
> one
> job was to be submitted from the same interactive session for
> this process,
> then another unique identifier other than the job number, would be
> essential.
> I need to know which will be the other best unique identifier.
>
> Please advise, your suggestions have helped me see brighter days :-).
>
>
>
> Thanks & Regards,
>
> Hrishikesh Kotwal
>
>
>
>
> _______________________________________________
> 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) 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.
