RPGLE/CL Enhancement Requests

RE:     Re: Additional RPGLE Enhancement Requests

Charlie said;
>>6.  Permit the name of an externally defined file to optionally show
>>    up in DSPPFMREF output.
>     D dsname   E DS    EXTNAME(filename)  LOG(*YES)
>     where filename is NOT defined in F-specs.

I said;

As I previously posted, what we REALLY need is a H-Spec keyword like
the file level DDS keyword "REF".   Then standalone "E" types could 
do something like    D FIELD      E        LIKE(*REF)
and have the compiler find it in my field reference file like the DDS
compiler does!!!!

By all means DON'T make me define a 3000 field externally defined 
data stucture(ie Field Ref. file)  when I will only use 3 fields in my
program!!!

(now then where was I,  keep reading below)  

------------------------------------
Greg said
>This is another absolute requirement.  I have situations where I pass
>an entire record format as a parameter between programs because the
>access method is fairly complicated.  I currently have to remember
>which files are accessed this way and manually scan for each program
>that uses this "API".  It would be ideal for this reference to show
>up on DSPPGMREF output.
>
>
>Greg Thielen

-----------------------------------------------

Greg 
I do the same thing ALOT.  I hardly ever pass individual parameters for
obvious reasons.  (If Hans is listening)  You also would probably love
to not having to HARD CODE some of your default values in those structures
and instead have those DeFaulT values come from the externally defined 
file's DDS's DFT values right, and have them change automatially if you
change the file and recompile the program right? 

On top of that how would you like the following idea when using externally 
defined structures as parameters; 

The only place where we have to work with Hard Coded From & To positions
with this technique is CL programs right? 

Now when using this technique our CL's would look something like this.

PGM  &PARM

DCL    &PARM    *CHAR    100   /* or total size */
DCL    &FIELD1  *CHAR      5   /* field 1 of parm */
DCL    &FIELD2  *CHAR     10   /* field 2 of parm */
DCL    &FIELD3  *DEC     (5 0) /* field 3 of parm */

/*  of course you can use a DCLF  PARMFILE to automatically 
    define the above fields */

CHGVAR   &FIELD1   %SST(&PARM 1  5)
CHGVAR   &FIELD2   %SST(&PARM 6 10)
CHGVAR   &FIELD3   %SST(&PARM 16 5)  /* of course Zoned decimal */

The trouble with this is we still have to HARD CODE the FROM & TO 
positions of the fields in the parameter.  If the parmfile changes
we have to get in and change the CL source member. Right?

How about this instead;

PGM    &PARM

DCLF   PARMFILE 

CHGVAR  &PARMFILE  &PARM


Thats it.

If you remember on the SYS/38 if we declared a data area
(yes DCLDTAARA) in a CL program, the system automatically declared
a variable for us with the same name & length of the data area.

Well, what we need is when we declare a file in CL, have the system 
automatically declare for us a variable for us (same size & name)  
as the file!  (while still declaring all the fields in the file)

If we change this "format" level variable, the systems automatically 
changes the fields in the format affected by the change! 
Just like a externally defined DS in RPG. 

In the above example, as soon as I changed the format level variable 
&PARMFILE,  variables &FIELD1 , &FIELD2, &FIELD3 will automatially
be initialized.  No hard coding offsets, lengths, nothing.
Like Externally defined structures in RPG,  If the parm file changes
(new fields added or changed) all we would have to do is recompile
the CL program. (same impact as externally defined DS's in RPG)

So how would you like to have "Structures" in CL? 

By the way this is just a dream of mine,  ROCHESTER owns CL.

So we will probably never see structures or subroutines, or multiple files
in CL ever I believe. (Hence my previous posts) CL has not changed
mechanically since 1980 I believe.(new OS/400 commands is not a change
and we didn't have to ask for ILE/CL they had to do it)

(For those interested and are going to COMMON don't miss Soundoff.)

John Carr CDP
EdgeTech



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *