CLRPFM / OVRDBF APIs ?
Mark Roberts
I have written a CSV converter on the AS/400 to enable propert FTP of data
to the PC network.
This is using all the mod-cons; RPG IV, embedded SQL and APIs (field
description retrieval etc.). Thus far I have been able to avoid the use of
any CL.
I have come across two problems. There don't appear to be APIs for CLRPFM
(so I can clear the destination file) or OVRDBF (so I can SQL INSERT into
multi-member files).
Currently I am using QCMDEXC to CLRPFM. Besides the lack of elegance in this
process, it doesn't return the feature rich error information that I have
come to find so useful with 'Proper' APIs (Error text would be nice!).
SQL DELETE is just too slow for clearing a large file, and it seems to leave
the file in an unreliable state for FIFO retrieval (this seems really
bizarre to me, maybe someone can shed some light...)
We are using V4R2, and are about 1 year out on PTFs (!)
Has anyone got any ideas ?
Thanks,
Mark.
Ken S.
On Sat, 12 Jun 1999 12:20:42 +0100, "Mark Roberts"
<M.A.L....@dial.pipex.com> wrote:
>I have come across two problems. There don't appear to be APIs for CLRPFM
>(so I can clear the destination file) or OVRDBF (so I can SQL INSERT into
>multi-member files).
This is not a supported function, but you can call the command
processing program for the CLRPFM command directly as an "API" to
clear a member. I believe the program name is QDBCLRPF. Do a DSPCMD
on the CLRPFM command to get the exact name. There are two
parameters. The first parameter is 20 bytes long and contains the
file name in the first 10 bytes and the library name in the last 10
bytes. The second parameter is 10 bytes long and contains the member
name. The acceptable values are exactly what is acceptable on the
CLRPFM command.
One of the nice benefits is that when you call the CPP directly, it
does NOT put a message in the joblog if the member was successfully
cleared, so if you are doing a lot of repeated clears, you don't
clutter up the joblog. And of course it runs faster this way.
Ken
http://www.ke9nr.org/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone else.
Dave McKenzie
and above (without taking drastic steps), because QDBCLRPF is a system
domain object :-)
--Dave
Njål Fisketjøn (Njal Fisketjon)
>Hi Mark -
>
>On Sat, 12 Jun 1999 12:20:42 +0100, "Mark Roberts"
><M.A.L....@dial.pipex.com> wrote:
>
>>I have come across two problems. There don't appear to be APIs for CLRPFM
>>(so I can clear the destination file) or OVRDBF (so I can SQL INSERT into
>>multi-member files).
>
>This is not a supported function, but you can call the command
>processing program for the CLRPFM command directly as an "API" to
>clear a member. I believe the program name is QDBCLRPF. Do a DSPCMD
>on the CLRPFM command to get the exact name. There are two
>parameters. The first parameter is 20 bytes long and contains the
>file name in the first 10 bytes and the library name in the last 10
>bytes. The second parameter is 10 bytes long and contains the member
>name. The acceptable values are exactly what is acceptable on the
>CLRPFM command.
>
>One of the nice benefits is that when you call the CPP directly, it
>does NOT put a message in the joblog if the member was successfully
>cleared, so if you are doing a lot of repeated clears, you don't
>clutter up the joblog. And of course it runs faster this way.
>
Ken,
could you please explain why it should run faster this way?
Njål Fisketjøn, FIGU DATA AS
n...@figu.no
http://www.robin.no/~nfisketj
Ken S.
On Sat, 12 Jun 1999 22:28:11 GMT, njal.fi...@figu.no (Njål
Fisketjøn (Njal Fisketjon)) wrote:
>>One of the nice benefits is that when you call the CPP directly, it
>>does NOT put a message in the joblog if the member was successfully
>>cleared, so if you are doing a lot of repeated clears, you don't
>>clutter up the joblog. And of course it runs faster this way.
>>
>
>Ken,
>
>could you please explain why it should run faster this way?
Either two or three reasons, depending on the way you are using the
CLRPFM command:
1. QDBCLRPF does not take the time and resources to write to the
joblog.
2. calling the command processing program directly eliminates OS/400
having to parse the command to get and validate the parameters to pass
to the CPP before calling the CPP.
3. and if you want to clear the member from inside of a RPG or other
non-CL program, by calling the CPP directly, you do not need to call
QCMDEXC or some other API or HLL function to initiate the processing
of the the CLRPFM command.
Njål Fisketjøn (Njal Fisketjon)
>Hi Njål -
>
>On Sat, 12 Jun 1999 22:28:11 GMT, njal.fi...@figu.no (Njål
>Fisketjøn (Njal Fisketjon)) wrote:
>
>>>One of the nice benefits is that when you call the CPP directly, it
>>>does NOT put a message in the joblog if the member was successfully
>>>cleared, so if you are doing a lot of repeated clears, you don't
>>>clutter up the joblog. And of course it runs faster this way.
>>>
>>
>>Ken,
>>
>>could you please explain why it should run faster this way?
>
>Either two or three reasons, depending on the way you are using the
>CLRPFM command:
>
>1. QDBCLRPF does not take the time and resources to write to the
>joblog.
>
>2. calling the command processing program directly eliminates OS/400
>having to parse the command to get and validate the parameters to pass
>to the CPP before calling the CPP.
>
>3. and if you want to clear the member from inside of a RPG or other
>non-CL program, by calling the CPP directly, you do not need to call
>QCMDEXC or some other API or HLL function to initiate the processing
>of the the CLRPFM command.
>
Remember that when running an IBM command there's no need to resolve a pointer to the program, since
an index to the SEPT (System Entry Point Table) is stored in the Command Object. Sometimes (Always?)
the resolve takes longer than parsing the command and executing the CPP via the command interface.
Of course, a message sent may as you say use more CPU than this step. I don't think the CPP writes
to the joblog, it only sends a message to the program message queue.
Using ILE, you can write a small CL LE module to clear the member, and bind that with the RPG module
and thus keep all within the boundaries of one *PGM.
Mark Pottorff
placing a msg in the joblog. But, the other reason is that any time you
run a *CMD object, you have the overhead of the command processor and
its validation of parms and then it has to call the CPP to get the work
done. So, APIs are always better performers than commands.
A thought on the OVRDBF... if you use an override scope of *JOB, I
believe you could get away with performing the override via the QCMDEXC.
"Njål Fisketjøn (Njal Fisketjon)" wrote:
>
> On 12 Jun 1999 06:56:27 PDT, Ken S. <ken@ke9nr.#nospam#.org> wrote:
>
> >Hi Mark -
> >
> >On Sat, 12 Jun 1999 12:20:42 +0100, "Mark Roberts"
> ><M.A.L....@dial.pipex.com> wrote:
> >
> >>I have come across two problems. There don't appear to be APIs for CLRPFM
> >>(so I can clear the destination file) or OVRDBF (so I can SQL INSERT into
> >>multi-member files).
> >
> >This is not a supported function, but you can call the command
> >processing program for the CLRPFM command directly as an "API" to
> >clear a member. I believe the program name is QDBCLRPF. Do a DSPCMD
> >on the CLRPFM command to get the exact name. There are two
> >parameters. The first parameter is 20 bytes long and contains the
> >file name in the first 10 bytes and the library name in the last 10
> >bytes. The second parameter is 10 bytes long and contains the member
> >name. The acceptable values are exactly what is acceptable on the
> >CLRPFM command.
> >
> >One of the nice benefits is that when you call the CPP directly, it
> >does NOT put a message in the joblog if the member was successfully
> >cleared, so if you are doing a lot of repeated clears, you don't
> >clutter up the joblog. And of course it runs faster this way.
> >
>
> Ken,
>
> could you please explain why it should run faster this way?
>
Paul Nicolay
In the whole story of doing CSV conversions, I believe the difference
between a CLRPFM via CL or a would be API, is non-existent. In addition, I
don't see the point in avoiding CL for writing the tool. In case you want
to limit it to a single *PGM, you can still use ILE-CL.
Regards,
Paul
----------------
Njål Fisketjøn (Njal Fisketjon) wrote in message
<376381ea...@news.robin.no>...
Remember that when running an IBM command there's no need to resolve a
pointer to the program, since
an index to the SEPT (System Entry Point Table) is stored in the Command
Object. Sometimes (Always?)
the resolve takes longer than parsing the command and executing the CPP via
the command interface.
Of course, a message sent may as you say use more CPU than this step. I
don't think the CPP writes
to the joblog, it only sends a message to the program message queue.
Using ILE, you can write a small CL LE module to clear the member, and bind
that with the RPG module
and thus keep all within the boundaries of one *PGM.
Njål Fisketjøn, FIGU DATA AS
n...@figu.no
http://www.robin.no/~nfisketj
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
Njål Fisketjøn
>Hi Njal,
>
>In the whole story of doing CSV conversions, I believe the difference
>between a CLRPFM via CL or a would be API, is non-existent. In addition, I
>don't see the point in avoiding CL for writing the tool. In case you want
>to limit it to a single *PGM, you can still use ILE-CL.
>
That's (ILE CL) what I've just said too. :)
Charles R. Pence
> <<SNIP>> I have come across two problems. There don't appear to
> (so I can SQL INSERT into multi-member files).
>
> process, it doesn't return the feature rich error information that I have
> come to find so useful with 'Proper' APIs (Error text would be nice!).
Why not just write a CLP which effects similar action and feedback, to what you expect from an API. Call that CLP directly instead of the QCMDEXC.
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.
Thomas Raddatz
error code in case of an unexpected error. Fell free to have a
look at my RPG-IV exmple below.
If you are on a newer release you can replace f_len() by %len or
if you are on the same or lower release you have to write your
own f_len() or replace it by a constant.
Documentation:
AS/400 Advanced Series: System API Reference OS/400 Program and CL Command APIs
*
* Definitionen für QCAPCMD
D cmdLen S 10I 0 INZ
D optCtrl DS
D typ_CmdPrc 1 4B 0 INZ(0) like QCMDEXC
D DBCS_Data 5 5A INZ('0') ignore DBCS
D prmt_Act 6 6A INZ('0') never prompt
D cmdStrSntx 7 7A INZ('0') AS/400 Syntax
D msgRtvKey 8 11A INZ(*BLANKS) no retrieve key
D res_01 12 20A INZ(*ALLx'00')
D optCtrlLen S 10I 0 INZ
D optCtrlFmt S 8A INZ('CPOP0100')
D cmd S LIKE(i_cmd)
D INZ
D lenAvl S 10I 0 INZ
D lenAvlRtn S 10I 0 INZ
*
* API error reporting
D §ErrorCode DS 256
D §ErrProv 1 4B 0 INZ(256)
D §ErrAvail 5 8B 0 INZ(0)
D §ErrID 9 15A INZ(*BLANKS)
D §ErrRes01 16 16A INZ(*BLANKS)
D §ErrDta 17 256A INZ(*BLANKS)
*
C Eval cmd = %subst(i_cmd: 1: dataLen)
C Eval cmdLen = f_len(cmd)
C Eval lenAvl = f_len(cmd)
*
C Eval optCtrlLen = f_len(OptCtrl)
*
C CALL 'QCAPCMD'
C PARM cmd
C PARM cmdLen
C PARM optCtrl
C PARM optCtrlLen
C PARM optCtrlFmt
C PARM cmd
C PARM lenAvl
C PARM lenAvlRtn
C PARM §errorCode
*
C If §ErrAvail <> 0
C Eval o_msgID = §errID
C Eval o_msgDta = §errDta
C Else
C Eval o_msgID = ' '
C Eval o_msgDta = ' '
C Endif
Mark Roberts schrieb:
>
> Hello,
>
> I have written a CSV converter on the AS/400 to enable propert FTP of data
> to the PC network.
>
> This is using all the mod-cons; RPG IV, embedded SQL and APIs (field
> description retrieval etc.). Thus far I have been able to avoid the use of
> any CL.
>
> I have come across two problems. There don't appear to be APIs for CLRPFM
> (so I can clear the destination file) or OVRDBF (so I can SQL INSERT into
> multi-member files).
>
> Currently I am using QCMDEXC to CLRPFM. Besides the lack of elegance in this
> process, it doesn't return the feature rich error information that I have
> come to find so useful with 'Proper' APIs (Error text would be nice!).
>
> SQL DELETE is just too slow for clearing a large file, and it seems to leave
> the file in an unreliable state for FIFO retrieval (this seems really
> bizarre to me, maybe someone can shed some light...)
>
> We are using V4R2, and are about 1 year out on PTFs (!)
>
> Has anyone got any ideas ?
> Thanks,
> Mark.
--
*=====================================================*
e-mail Adresse:
Thomas....@Online-Club.de
Homepage:
http://www.online-club.de/~Thomas.Raddatz/
*=====================================================*
Bob Cozzi
Remember, CLRPFM is one of a large group of CL commands that IGNORE the
OVRDBF command.
--
Bob Cozzi
www.rpgiv.com
Mark Roberts <M.A.L....@dial.pipex.com> wrote in message
news:7jtfpp$i8i$1...@lure.pipex.net...
Marty Winkler
example from remote system to AS400 with replace of data in member.
get xxxxremotefilexxxx mylib/myfile.mrmbr (replace
example from AS400 to remote system
put mylib/myfile.mymbr xxxxremotefilexxxx
If a remote file of that name already exists, the contents are
replaced by
the contents of the local file unless Store Unique (SUNIQUE) is on.
This is a toggle switch.
You might also check out the RUNRMTCMD, RCMD,RMTCMD....depending on
what system you are on.
Mark Roberts
INSERT statement into the correct member, after I have used CLRPFM to clear
it (I would use SQL DELETE, but for the fact that it's very slow!)
Thanks,
Mark.
Bob Cozzi wrote in message <3767...@news1.us.ibm.net>...
>Mark,
>
>Remember, CLRPFM is one of a large group of CL commands that IGNORE the
>OVRDBF command.
>
>--
>
>Bob Cozzi
>www.rpgiv.com
>
>
>Mark Roberts <M.A.L....@dial.pipex.com> wrote in message
>news:7jtfpp$i8i$1...@lure.pipex.net...
Mark Roberts
This is, I believe, the best bet yet! I never knew of this API, but it seems
to return the kind of information that I require, in the format that I
require.
Thanks, also, to everyone else who has contributed to this thread - it's
most appreciated!
Mark.
Thomas Raddatz wrote in message <3766B7F0...@online-club.de>...
>> Hello,
>>
>> I have written a CSV converter on the AS/400 to enable propert FTP of
data
>> to the PC network.
>>
>> This is using all the mod-cons; RPG IV, embedded SQL and APIs (field
>> description retrieval etc.). Thus far I have been able to avoid the use
of
>> any CL.
>>
>> I have come across two problems. There don't appear to be APIs for CLRPFM
>> (so I can clear the destination file) or OVRDBF (so I can SQL INSERT into
>> multi-member files).
>>
>> Currently I am using QCMDEXC to CLRPFM. Besides the lack of elegance in
this
>> process, it doesn't return the feature rich error information that I have
>> come to find so useful with 'Proper' APIs (Error text would be nice!).
>>
>> SQL DELETE is just too slow for clearing a large file, and it seems to
leave
>> the file in an unreliable state for FIFO retrieval (this seems really
>> bizarre to me, maybe someone can shed some light...)
>>
>> We are using V4R2, and are about 1 year out on PTFs (!)
>>
>> Has anyone got any ideas ?
>> Thanks,
>> Mark.
>