RE: Re[2]: Fw: File in CL Program -- RPG400-L

Jodi:

If this is a troll, I'll bite.

In 1986, I wrote the most coolest WRKACTJOB in the whole world for system
38 - faster than DSPACTJOB, faster than WRKACTJOB, about as fast as
WRKSYSACT, and very high function.  When the customer moved to AS/400 it
stopped working along with a bunch of other MI code that I wrote.  You see,
I hacked the data areas and wrote directly to them.  I also used the MI
instruction Set Access State to triple buffer the Work Control Block Table
in 256 K chunks.  That command could scan 5,000 jobs for submitter job and
user in less than one second.

Is it possible to make the existing RCVF command update a file?  Absolutely!
But do you want that command running on your machine?  This particular set
of "wings and engine" broke later and I wasn't around to fix it.

I am not certain what you mean by, "which is a communication COMMAND".  If
you look up the RCVF command in the reference manual, you will see that it
is the "read a database record into a CL program" command.  It has nothing
to do with TCPIP or SNA although it can be used to read a record from a
display file.   There is also a SNDF CL command and a SNDRCVF CL command.
As far as I know, they only work for display files.  I suppose that they
could be overridden but I don't recall ever trying it.

Or, are you thinking that since it is a COMMAND, it is somehow easy to
rewrite or modify?  Just like the first paragraph, I can change the way that
the existing RCVF works or replace it with something that works another way.
Remember, if you change how RCVF works, it is quite likely that some IBM
code may not expect your change.

I don't understand this sentence, "clifford's db i/o utlities are not
invoked by a CALL to a program - they are simple commands like READ, UPDATE,
WRITE - used the same as RCVF with parameters, arguments & keyflds, etc."

Start a job trace then run a CL program containing RCVF and see how many
programs get called to implement the command analyzer interface (probably 3
to 6) before calling the program that actually does the work.  Then you will
see three layers of operating system data management and database programs -
QDMCOPEN, QDBOPEN, QDBGET.  Inside the QDBGET program is an MI instruction
that goes into the microcode where two more layers of calls are executed.
The database get MI instruction will call VLIC program #dbbring, and that
will call other storage management routines in the microcode that will
generate a disk IO request then talk to the disk drives for the information.
In order to perform the IO, the program must allocate a chunk of memory for
a record buffer.  If the program is ILE, the allocation will occur on the
heap.  If OPM, the allocation will be in PSSA.  If a free memory page isn't
available for the IO to use, the microcode will signal SMPOL0001 to create a
free memory frame for the VMC buffer.  The job trace won't show you the
"database get" MI instruction (or any of the program instructions) or any of
the stuff below the MI layer.

I don't know what your impression is of all of this but I think that it is
fairly complex - especially since I left out ALL the memory, invocation
stack, variable storage, disk IO, and exception handling details.  If you
want to see those, I can point you to a place where you can download the
SMTRACE library.  Then you can see every complex MI instruction, program
call, and physical IO that the system performs on your behalf.  My current
record for SMTRACE output is 50,000 printed pages from a 5 minute
system-wide data collection.  If you are interested in the real gory
details, there is an instruction trace that you can turn on.  It will write
about 100 million 64-bit words per second if the machine is running at 100
percent and has one CPU.

RCVF is not a simple command any more than WRKSYSACT is.  The only
difference between RCVF in a CL program and READ in an RPG program is the
command analyzer - RPG gets to skip the CA component.  Commands are slightly
MORE complex than program calls.

The answer that "it is impossible to update a file in a CL program"
overstates the facts.  It is impossible to update a file inside a CL
program, if (1) you limit yourself to the CL commands that IBM ships, )2)
you don't call a program to perform the update or cause a message to be sent
to another program or job that performs the update, or (3) you ignore
command operations that normally update database files like the some of the
DST commands.  If you let me write my own commands that call my programs
written to do what I want, then I can recreate Mr. Clifford's functionality.
But you were complaining that we didn't demonstrate our creativity.  How
much creativity do you want in your application systems?  Could I interest
you is a VERY fast WRKACTJOB command?  I know how to do some very cool
things but that doesn't make it a good idea.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Jodi Walker
Sent: Tuesday, August 29, 2000 2:35 PM
To: RPG400-L@midrange.com
Subject: Re[2]: Fw: File in CL Program


     perhaps i am missing something. please explain to me the difference
     between using RCVF, which is a communication COMMAND, and one of these
     db i/o COMMANDS to manipulate a database file. RCVF is just a front
     end to other code - the same as these utlities. i'm not saying that
     the code that supports RCVF is RPGLE - i am saying that the ability to
     use RCVF is dependent upon code outside of the CLP that it is used in.
     mr. clifford's db i/o utlities are not invoked by a CALL to a program
     - they are simple commands like READ, UPDATE, WRITE - used the same as
     RCVF with parameters, arguments & keyflds, etc.

     other than the fact that one is IBM supplied and the others are
     home-grown and have observable code, I don't see a practical
     difference. that is why i said it was possible 'with a little help.'

     i'd rather have someone answer the 'is it POSSIBLE' question with some
     creativity rather than a simple 'no.'  if i have two candidates, one
     who says 'no' and one who says, in effect, 'not with IBM supplied
     commands, but it is possible if...' guess who i am inclined to hire?

     is it possible for man to fly? no. but if he built a machine with
     wings and an engine....

     jw



______________________________ Reply Separator
_________________________________
Subject: Re: Fw: File in CL Program
Author:  "Mike Silvers" <msilvers@hbs-inc.com> at Internet
Date:    08/29/2000 2:52 PM


This code does not allow you to update a file using CL, it uses RPGLE
programs to do the file manipulation.  You still can not update a file in CL
only.


----- Original Message -----
From: Jodi Walker <Jodi_Walker@ccmail.columbia.com>
To: <RPG400-L@midrange.com>
Sent: Tuesday, August 29, 2000 11:48 AM
Subject: Re: Fw: File in CL Program


>      Actually, yes it is possible to update a db file in a CL.  In fact,
>      you can do more than update - IF you have a little help.  Read the
>      article at
>
http://www.as400network.com/artarchive/index.cfm?fuseaction=viewarticl
>      e&CO_ContentID=7217
>
>      then download & install the code.  I couldn't resist trying it & it
>      works like a champ.
>      If the link doesn't work, just search the AS400 network site for the
>      article called 'CL flexes its database muscles' by Peter Clifford.
>
>      Things you can do with these db i/o commands in CL:
>      Open a db file
>      Close a db file
>      Read a record from a db file
>      Position the file cursor in a db file
>      Update a record in a db file
>      Write a record to a database file
>      Delete a record from a database file
>      Release a locked record
>      Retrieve the value of a named field from a record format
>      Change the value of a named field in a record format
>
>         jw
>
> ______________________________ Reply Separator
_________________________________
> Subject: Fw: File in CL Program
> Author:  Nancy Savino <newnancy@juno.com> at Internet
> Date:    08/29/2000 7:47 AM
>
>
>
>
> --------- Forwarded message ----------
> From: Nancy Savino <newnancy@juno.com>
> To: RPG400-L@midrange.com
> Date: Fri, 25 Aug 2000 11:18:56 -0400
> Subject: File in CL Program
> Message-ID: <20000825.112007.-159601.0.newnancy@juno.com>
>
> I recently went on an interview. (By the way, I am the one who has been
> looking for a job for over a year and has not found one yet). He asked me

> about files in CL programs. I told him that there can only be one, that I
> have read database files in a CL program in a loop, etc. Can you update a
> database file in a CL program? I told him that I never had done that.
>
> Sincerely, Nancy
>
> ________________________________________________________________
> YOU'RE PAYING TOO MUCH FOR THE INTERNET!
> Juno now offers FREE Internet Access!
> Try it today - there's no risk!  For your FREE software, visit:
> http://dl.www.juno.com/get/tagj.
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---