ducking for cover (was File in a CL program) -- RPG400-L

     with comments to selected statements posted by Richard Jackson:
     
     <snip>This particular set of "wings and engine" broke later and I 
     wasn't around to fix it.<snip>
     Yes, and before the 747 there was that thing with the Hindenburg.  The 
     point is that an effort was made and lessons were learned.  And, no, I 
     am not equating the failure of a command to the loss of life caused by 
     the Hindenburg. Planes still crash, and so do 400s, but we keep 
     pressing on, always improving, never letting the 'impossible' stop us 
     from trying.
     
     <snip>
     I am not certain what you mean by, "which is a communication 
     COMMAND".<snip>
     my fingers got behind the speed of my thought - i did not mean a 
     communication command in the sense of TCP/IP or SNADS.  i meant a 
     method that allows communication between CL and the DB.  communication 
     was a poor choice of words in this forum & context, but one that i 
     typically invoke when trying to explain something to users in a way 
     that they understand.
     
     
     <snip>Is it possible to make the existing RCVF command update a 
     file?<snip>
     i wasn't talking about making the existing RCVF do anything, but now 
     that you mention it...
     
     <snip>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.<snip>
     Yep, I know, but since we were talking about db files and I don't 
     think they can be OVR to apply to a db, I didn't mention them.
     
     <snip>Or, are you thinking that since it is a COMMAND, it is somehow 
     easy to rewrite or modify?<snip>
     No, i wasn't talking about modifying ANY IBM command, nor would I 
     suggest such a thing be done in a local shop, nor would I support 
     someone doing such a thing outside of IBM labs. 
     
     I don't understand how you can take text that compares two things, the 
     RCVF command and any of mr. clifford's db i/o commands, and come to 
     the conclusion that I was talking about, or even hinting at, a local 
     programmer modifying an existing IBM command.  It's not good 
     programming. It was a simple comparison that although IBM's RCVF 
     command is much more complex than the READ db i/o cmd from mr. 
     clifford, that they were used in the same manner in a CLP and that, 
     functionally, they both were basically front ends to other processes 
     (programs, procedures, buffer crunching, whatever) that performed the 
     DB related actions.
     
     <snip>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."<snip>
     
     then let me illustrate. imagine a CL where READREC is an RPG that 
     reads a file and returns the record to the CL. Read is one of mr. 
     clifford's db i/o cmds:
     
     CALL READREC parm(&HistFil &HistRec)
     READ       HANDLE(&HistoryHdl)           
                DATALEN(100)                  
                RTNDATA(&HistoryRcd)          
                RTNDATALEN(&HistoryLen)       
                OPTION(*KEY)                  
                KEY(&ISOChkDate)              
                KEYLEN(10)  
     RCVF 
     
     can you see what i mean now? sometimes it is easier to use a specific 
     rather than try to explain. the CALL command is explicitly coded into 
     the CL, thus invoking the  specified program, whereas the other 
     commands that, of course, executes a program, but the CALL itself is 
     not visible in this CL.  with your excellent explanation of the RCVF, 
     you made my point exactly - which was that RCVF does indeed call 
     programs just as the READ db i/o does.  that was my whole point.  had 
     i known the intricate detail that you did, i would have been able to 
     make that more clear. in no way to i imply that RCVF was simple. (and, 
     of course, the CALL command does its own invocation of pgms, 
     what-have-you, to enable the program READREC to be executed.)         
     
     
     <snip>The answer that "it is impossible to update a file in a CL 
     program" overstates the facts. <snip>
     yes - again, my point exactly.
     
     <snip>But you were complaining that we didn't demonstrate our 
     creativity.<snip>
     Noooo, I was stating that an answer of 'it is impossible to update a 
     file in a CL program' demonstrates a lack of creativity, although it 
     is correct in the textbook sense that IBM did not provide a direct and 
     supportable method to update a file in a CL.  The rest of your 
     paragraph 
     <snip>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.  <snip>
     demonstrates creativity - your conditions show ways to MAKE it 
     possible.
     
     <snip>I know how to do some very cool things but that doesn't make it 
     a good idea.<snip>
     Yeah, I know.  My well known, oft invoked and much abused motto in our 
     PA meetings is 'just because you can doesn't mean you should.'
     
     My lack of effective communication (that is, written words, not SNADS 
     <bg>) has obscured the fact that I have exactly the same idea as you.
     
     Maybe I should have just stated something like 'yeah, well, RCVF calls 
     programs, too.'
     
     At any rate, you have provided me with some interesting things to 
     research just for the sake of knowledge. I wasn't trolling, but, nice 
     bite. 
     
     thanks for the lesson
     jw
     
     i just noticed - why the heck was this asked in the RPG400 forum 
     anyway?  had i seen that earlier, i wouldn't have replied in this 
     forum. sorry.  
+---
| 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
+---