|
The problem I have with using OPTIONS(*STRING) or %STR() is that they don't have an option to do blank truncation off the field's value. In C, obviously, a "field" of length 256 may have 10 bytes of data in it with an 11th byte of X'00' to indicate the end of data. In RPG and database, we have a field that is 256 and if there are 10 bytes of data and 246 blanks, the field gets passed as 256 and includes the blanks. I'd like to see an OPTIONS(*TSTRING) to indicate to the compiler to do, effectively a %TRIMR() to the field before sending it. 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 Jon Paris > Sent: Thursday, December 13, 2001 11:54 AM > To: rpg400-l@midrange.com > Subject: Procedure parameter with VALUE option > > 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 > > > > -- > > _______________________________________________ > 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.
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
