|
I wrote a small procedure using the QCAPCMD API to perform the CHKOBJ command. Mike Richardson -----Original Message----- From: rpg400-l-request@xxxxxxxxxxxx [mailto:rpg400-l-request@xxxxxxxxxxxx] Sent: Wednesday, August 06, 2003 4:41 AM To: rpg400-l@xxxxxxxxxxxx Subject: RPG400-L Digest, Vol 2, Issue 542 Send RPG400-L mailing list submissions to rpg400-l@xxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.midrange.com/mailman/listinfo/rpg400-l or, via email, send a message with subject or body 'help' to rpg400-l-request@xxxxxxxxxxxx You can reach the person managing the list at rpg400-l-owner@xxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of RPG400-L digest..." Today's Topics: 1. RE: Adoption of new RPG techniques (Joe Pluta) 2. RE: Adoption of new RPG techniques (Joe Pluta) 3. Adoption of new RPG techniques (Jon Paris) 4. Re: Adoption of new RPG techniques (James Rich) 5. RE: Adoption of new RPG techniques (Joe Pluta) 6. RE: Adoption of new RPG techniques (Marco Facchinetti) 7. QUSROBJD API (Luis Martins) 8. Re: QUSROBJD API (Marco Facchinetti) 9. Re: QUSROBJD API (Carsten Flensburg) ---------------------------------------------------------------------- message: 1 date: Tue, 5 Aug 2003 17:45:24 -0500 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: Adoption of new RPG techniques > From: James Rich > > I'm not sure why you think that I believe that the extended factor 2 is > not part of RPG. I never said or implied any such thing. Considering the fact that I write for a living, I really didn't express myself very well, James. I apologize. In one of your prior posts you said: >> To use such a field you need free format code >> (unless you use the "loose fixed format" of eval+extended factor 2). This implied that you considered extended factor two somehow "above and beyond" standard fixed format RPG IV. My point was that most of the things you included as benefits of /free are indeed available in fixed format RPG IV. The extended factor two is what makes /free so superfluous. > I think I see where our two points of view differ. Your article nicely > points out a method that makes the free format precompiler directive > (/free) unnecessary. IOW, I understand your point to be that you are > not against free format style coding, but against the /free directive. Yes, but for more than just the fact that it is unnecessary. I also dislike the fact that it makes your code "modal", and in the /free mode, some normal operations like MOVE no longer work, or work differently. The decision by the compiler team to remove functionality in order make use of the /free syntax is the primary object of my concern. > My point is that since it is the free format style of the extended > factor 2 that we all like (and indeed use all the time) that fixed > format style coding is what is superfluous. All the arguments against > free format code with the exception of your MOVE argument rely on making > use of the free format capabilities of the extended factor 2. So it > seems truly odd to me that there are people who are against free format > code when they use it all the time (and like it - in fact prefer it as > long as it starts in column 36). You miss the point - it is the loss of the MOVE operation, and the fact that mathematical operations no longer work the same, and the loss of syntax checking, and the unnecessary requirements for semicolons - it is these things that make /free an onerous change. Where a simple extension to the fixed format could have made for a seamless change, the compiler team instead made it unnecessarily difficult to move from one syntax to the other, and it is that with which I disagree. It is not that /free is bad. It is just that its benefits do not make up for the things the compiler team decided we must lose to get there. And it's especially distasteful because there are no sound reasons for the losses. > > Have you actually tried using fixed format RPG IV, James? You seem to > > Yes, all day long. But assuming I said something that was true, would > my background somehow make it false? No, but the errors in your assumptions undermine the credibility of your statements. ------------------------------ message: 2 date: Tue, 5 Aug 2003 17:46:22 -0500 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: Adoption of new RPG techniques > From: Booth Martin > > Joe Pluta and I agree yet again. Gz, Booth. Isn't this the second sign of the Apocalypse? <grin> ------------------------------ message: 3 date: Tue, 5 Aug 2003 19:01:00 -0400 from: "Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx> subject: Adoption of new RPG techniques >> More real estate is better, but is it enough of an improvement to lose syntax checking? Ugh. I wouldn't want to force that on my programmers. In that case I guess you don't mind about not having MOVE in /Free Joe 'cos you won't be using it anyway. <huge grin> - sorry - couldn't resist! I'm off on two weeks vacation - so I'll leave you guys to duke it all out. I suspect that this debate may still be raging when I get back! Jon Paris Partner400 www.Partner400.com ------------------------------ message: 4 date: Tue, 05 Aug 2003 18:54:23 -0600 from: James Rich <james@xxxxxxxxxxx> subject: Re: Adoption of new RPG techniques Joe Pluta wrote: >>>To use such a field you need free format code >>>(unless you use the "loose fixed format" of eval+extended factor 2). > > This implied that you considered extended factor two somehow "above and > beyond" standard fixed format RPG IV. My point was that most of the > things you included as benefits of /free are indeed available in fixed > format RPG IV. The extended factor two is what makes /free so > superfluous. Ah. Yes, I can see where you are coming from. Like almost every argument, a lot of confusion comes about because of a lack of defining terms. People tend to make strong statements without really agreeing on what the terms mean that they are talking about. So let me define what I'm talking about (in case anyone is even reading this thread anymore): In an earlier post I said: If we stuck to what I'm going to call "true fixed format" then we would have: <indicators> <factor 1> <operator> <factor 2> <result> <indicators> The above is how I define fixed format. It is the syntax that RPG/36, RPG II, and RPG III use. With RPG IV we got a new syntax, something I called "loose fixed format" that consists of indicators, factor 1, opcode, and a new extended factor 2. This new extended factor 2 is really just a free format section of code within an otherwise fixed format syntax. In order to emphasize the fact that the extended factor 2 provides us with a free form style syntax I'm going to refer to this mixed syntax of RPG IV as "fixed-free". Fixed-free syntax looks like: <indicators> <factor 1> <operator> <free format area> This is the extended factor 2 syntax that we are familiar with as part of RPG IV. "True free format" syntax I'm going to define as syntax that has none of the fixed elements, i.e: <free format area> It seems a little pedantic to include that definition - but let's be complete. The interesting part to notice from this whole discussion is that we all primarily code in the free format area of fixed-free syntax. So much so that it seems wasteful to have to the fixed areas of fixed-free syntax. Following the suggestions of coding *EXTFACT2 in factor 1 would completely obviate the need for any code at all in the fixed area. So why have any fixed format at all? With some definitions in place we can look at that question. One argument in favor of fixed format is that it is legible to RPG programmers. That argument is silly, since because true free format is just that, free format, you can format the code to look anyway you want, including making it looked like fixed-free code looks. If you think that the current fixed-free syntax of RPG IV is easy to read, then just keep indenting things that way. Another argument against true free format code is the required uses of the /free precompiler directive. I agree that this kind of sucks. If a precompiler directive is necessary, I personally would have chosed to use /fixed to indicate areas the follow RPG IV's fixed-free syntax and defaulted to true free form syntax otherwise. But perhaps the best solution is to do what someone else mentioned a while ago and use the C in column 6 to indicate fixed-free vs. true free format code. Put a C in column 6 when you want fixed-free and leave it blank when you want true free format. Another argument against true free format syntax is that the syntax checker doesn't work with it. This isn't really a problem with true free syntax or the compiler, but with the editor. Emacs, vi, and other editors can check true free format code, RPG editors should do the same. Perhaps SEU is not the editor to do that with, however. Yet another argument against true free format syntax (YAAATFFS) is that following programmers will have a hard time with the indenting style chosen by the previous programmer. This is simply solved by code beautifiers such as those available for C. A standard beautifier such as the unix utility 'indent' could handle this without issue (indent also checks syntax - a nice bonus). Now for the hairy stuff - addressing the MOVE issue. I'm afraid that this will never be resolved in a way that Joe likes because so many (myself included) don't like the MOVE opcode. The biggest uproar over this issue has been because some view MOVE as being removed from the language and others see it as simply not being moved forward into true free form syntax. Possibly the solution involving the C in column spec would pacify both camps, but I'm not counting on it. I think those are the main arguments that have come up so far. But there has been an underlying argument that I don't think has been directly addressed: backward compatibility. I am interested by the statement "RPG is too backwards compatible". While argueing neither for nor against, I wonder what good or bad would come if RPG forked and a new, non-backwards compatible branch developed that contained many of the enhancements that have been asked for. RPG IV as it stands now would still be supported, but no longer evolve. Maybe call this new version something else, like FIR (FIR Isn't RPG - clever recursive acronym). It would have record level access, chain, external files, true free form, proper pointers, good SQL syntax, etc. but wouldn't support fixed-free or true fixed format at all. Hopefully I've clearly stated the definitions and arguments. If there is anyone left reading this thread perhaps we'll understand each other better. >>Yes, all day long. But assuming I said something that was true, would >>my background somehow make it false? > > > No, but the errors in your assumptions undermine the credibility of your > statements. True. Happily I learned something new today about RPG. James Rich ------------------------------ message: 5 date: Tue, 5 Aug 2003 22:16:12 -0500 from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> subject: RE: Adoption of new RPG techniques > From: James Rich > > Now for the hairy stuff - addressing the MOVE issue. I'm afraid that > this will never be resolved in a way that Joe likes because so many > (myself included) don't like the MOVE opcode. It's not me. According to the poll, my email and the responses online, over 60% of people agree. And then there's the millions of lines of code that have to be rewritten. The issue is not "like" or "dislike", it's "convert" or "rewrite". It's a very simple business issue, and when business issues get obscured because of likes and dislikes, egos, or "elegance", then it's the end users who end up paying, in higher cost of business. You don't like MOVE? Rewrite your code! We in the MOVE camp aren't forcing you to use it! But if you remove the MOVE, then you are imposing your likes and dislikes on those of us who use the opcode, as well as on millions upon millions of lines of legacy code. You need an awfully large ego to justify that sort of decision. > The biggest uproar over > this issue has been because some view MOVE as being removed from the > language and others see it as simply not being moved forward into true > free form syntax. Semantic and pedantic. Regardless of how you word it, the effect is the same. By removing the MOVE opcode from free format a minority of programmers (and if you look at the results, it's a relatively small minority at that) are imposing their ideas on the majority. Whereas by leaving the MOVE or at least providing a BIF, nobody is imposing anything on anyone. It's unfathomable to me that someone has so large an ego that they think it's okay to force people to change working code just because they find a basic, fundamental opcode too hard to understand. Again I say, if you don't like the MOVE, then rewrite your code! But from what I see only about 10% of the people have done that. And them haven't gone back and rewritten their entire applications just to get rid of MOVEs. James, have you gone through every program in your shop and rewritten all the MOVE instructions out? How many shops do you think have? And why do you think that is such a small number? Anyway, we've rehashed this many times. And as far as I'm concerned, the people have spoken in no uncertain terms. Removing MOVE is a bad move. Joe ------------------------------ message: 6 date: Wed, 6 Aug 2003 00:19:45 -0700 (PDT) from: Marco Facchinetti <facchinetti@xxxxxxxxx> subject: RE: Adoption of new RPG techniques As Iseries programmer I agree but think about somebody used to VB or something similar.. Marco --- Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote: > > So, to try to force the majority of people to move to > /free for what is > in effect no real value add is not progress. It's change > for change's > sake, in my opinion. > > Joe > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------ message: 7 date: Wed, 6 Aug 2003 08:51:11 +0100 from: "Luis Martins" <lnmartins@xxxxxxxxxxxx> subject: QUSROBJD API Can any one tell me how can use this API (QUSROBJD) to know if an object exist ? Thank You ! Luis Martins (Portugal) __________________________________________________ Esta mensagem e quaisquer ficheiros anexos são confidenciais, destinando-se ao uso exclusivo da pessoa e/ou entidade a que se dirigem. Caso não se lhe destine, ou não seja responsável pelo seu encaminhamento ao destinatário, informamos que a recebeu por engano. Qualquer utilização, distribuição, reencaminhamento ou outra forma de revelação a terceiros, impressão ou cópia são expressamente proibidos; sendo que agradecemos que destrua a mensagem de imediato, informando o seu emissor ou o Finibanco do sucedido. Não obstante o Finibanco utilizar software anti-vírus como precaução, não é possível garantir que a presente mensagem e eventuais ficheiros anexos não contêm vírus, pelo que não consideramos da responsabilidade desta instituição eventuais consequências inerentes. Alerta-se, ainda, que as mensagens transmitidas por este meio podem ser interceptadas, corrompidas, perdidas, destruídas ou entregues com atraso ao destinatário. ------------------------------ message: 8 date: Wed, 6 Aug 2003 02:21:54 -0700 (PDT) from: Marco Facchinetti <facchinetti@xxxxxxxxx> subject: Re: QUSROBJD API The API will return a CPF9801 if the object doesn't exist. But why not writing a very small module in CL using the CHKOBJ command? HTH Marco --- Luis Martins <lnmartins@xxxxxxxxxxxx> wrote: > > > > Can any one tell me how can use this API (QUSROBJD) to > know if an object > exist ? > > Thank You ! > > Luis Martins > (Portugal) > __________________________________________________ > > Esta mensagem e quaisquer ficheiros anexos são > confidenciais, destinando-se > ao uso exclusivo da pessoa e/ou entidade a que se > dirigem. Caso não se lhe > destine, ou não seja responsável pelo seu encaminhamento > ao destinatário, > informamos que a recebeu por engano. Qualquer utilização, > distribuição, > reencaminhamento ou outra forma de revelação a terceiros, > impressão ou > cópia são expressamente proibidos; sendo que agradecemos > que destrua a > mensagem de imediato, informando o seu emissor ou o > Finibanco do sucedido. > Não obstante o Finibanco utilizar software anti-vírus > como precaução, não é > possível garantir que a presente mensagem e eventuais > ficheiros anexos não > contêm vírus, pelo que não consideramos da > responsabilidade desta > instituição eventuais consequências inerentes. Alerta-se, > ainda, que as > mensagens transmitidas por este meio podem ser > interceptadas, corrompidas, > perdidas, destruídas ou entregues com atraso ao > destinatário. > > > > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries > (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: > http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the > archives > at http://archive.midrange.com/rpg400-l. > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------ message: 9 date: Wed, 6 Aug 2003 13:41:35 +0200 from: "Carsten Flensburg" <flensburg@xxxxxxxxxx> subject: Re: QUSROBJD API Hello Luis, Here's an RPG/IV sample: **-- Header specifications: --------------------------------------------** H Option( *SrcStmt ) **-- Global variables: -------------------------------------------------** D ObjNam s 10a D ObjLib s 10a D ObjTyp s 10a **-- Api error data structure: -----------------------------------------** D ApiError Ds D AeBytPro 10i 0 Inz( %Size( ApiError )) D AeBytAvl 10i 0 Inz D AeMsgId 7a D 1a D AeMsgDta 128a **-- Object description structure OBJD0100: ----------------------------** D RoData Ds D RoBytRtn 10i 0 D RoBytAvl 10i 0 D RoObjNam 10a D RoObjLib 10a D RoObjTypRt 10a D RoObjLibRt 10a D RoObjASP 10i 0 D RoObjOwn 10a D RoObjDmn 2a D RoObjCrtDts 13a D RoObjChgDts 13a D RoExtAtr 10a D RoTxtDsc 50a D RoSrcF 10a D RoSrcLib 10a D RoSrcMbr 10a **-- Retrieve object description: --------------------------------------** D RtvObjD Pr ExtPgm( 'QUSROBJD' ) D RoRcvVar 32767a Options( *VarSize ) D RoRcvVarLen 10i 0 Const D RoFmtNam 8a Const D RoObjNamQ 20a Const D RoObjTyp 10a Const D RoError 32767a Options( *VarSize ) ** **-- Get Web value: ----------------------------------------------------** ** C Eval ObjNam = '???' C Eval ObjLib = '*LIBL' C Eval ObjTyp = '*PGM' ** C CallP RtvObjD( RoData C : %Size( RoData ) C : 'OBJD0100' C : ObjNam + ObjLib C : ObjTyp C : ApiError C ) ** C If AeBytAvl > *Zero And C AeMsgId = 'CPF9801' **-- Object doesn't exist... C EndIf ** C Return ** Best regards, Carsten Flensburg ----- Original Message ----- From: "Luis Martins" <lnmartins@xxxxxxxxxxxx> To: <rpg400-l@xxxxxxxxxxxx> Sent: Wednesday, August 06, 2003 9:51 AM Subject: QUSROBJD API Can any one tell me how can use this API (QUSROBJD) to know if an object exist ? ------------------------------ _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) digest list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. End of RPG400-L Digest, Vol 2, Issue 542 ****************************************
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
