|
midrange.com
QUSROBJD is a good choice for an API to see if an object exists.
In the RPG ToolKit I use it in a procedure named ChkObjExists().
Here's the source for it if you don't have the toolkit, but the basis is to
check for any 'CPF98' message.
**************************************************************
** C H K O B J E X I S T - ChkObjExist (Check for Object Existence)
** (c) Copyright 2003 by Robert Cozzi, Jr.
**************************************************************
P ChkObjExists B Export
D ChkObjExists PI 1N
D szObjName 21A Const
D szObjType 10A Const
D szObject DS 21
D szName 10A
D szLib 10A
D bExists S 1N
** Check if the user object exists.
** If it does not exist, then return FALSE (*OFF)
** If it does exist, then return TRUE (*ON)
** The API QUSROBJD is used to attempt to retrieve
** the object's description. If CPF98xx is generated,
** then the object does not exist or the caller does
** not have object authority.
C eval szObject = CvtCase(szObjName:CC_TOUPPER)
C eval szObject = CvtQualName(szObject)
C Clear RTK_Error
C eval tk_errLen = %size(rtk_error)
C CallP QusRtvObjD(QUSD0100 : %size(QUSD0100) :
C 'OBJD0100' : szObject : szObjType :
C rtk_error)
** CPF9801 E - Object &2 in library &3 not found.
** CPF9802 E - Not authorized to object &2 in &3.
** CPF9803 E - Cannot allocate object &2 in library &3.
C
C eval bExists =
C NOT (%subst(tk_errMsgID:1:5) = 'CPF98' )
C return bExists
PChkObjExists E
Bob Cozzi
Cozzi Consulting
www.rpgiv.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Mike Richardson
Sent: Wednesday, August 06, 2003 10:24 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: QUSROBJD API
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
****************************************
_______________________________________________
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.
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.
