|
Hi Jon, I agree with the VARYING idea, but the OPTIONS(*STRING) is not necessarily a good idea because the api does not expect a null-terminated string (otherwise how could you write x'00' to the file?), hence the api's length parameter. However, none of that answers why the method shown doesn't work. And although I will probably change how I do it, I'd still like to know. And I'd like to know the basic difference between VALUE and CONST. Thanks, Peter Dow Dow Software Services, Inc. 909 425-0194 voice 909 425-0196 fax ----- Original Message ----- From: "Jon Paris" <Jon.Paris@Partner400.com> To: <rpg400-l@midrange.com> Sent: Thursday, December 13, 2001 9:53 AM 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. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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
