Re: V5R2: Source now allowed in the IFS -- MIDRANGE-L

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
It would be very easy to store this data in the OIR.  If they can display
a path name in WRKLNK, I am sure they can figure out a way to do this. And
so on for API's, etc.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




"Mark Waterbury" <mark.s.waterbury@worldnet.att.net>
Sent by: midrange-l-admin@midrange.com
10/18/2002 04:37 PM
Please respond to midrange-l


        To:     <midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        Re: V5R2:  Source now allowed in the IFS


Hello, Rob:

When you do a DSPPGM on an ILE "bound" *PGM, you must
then use option 5=Display on each *MODULE to see where the
source is, because for ILE, the one-to-one relationship between
object and source is at the module level.

Even so, how can you possibly store a (potentially very long) fully
qualified IFS path name in the space (only 30 bytes for file, library,
and member) reserved in the OIR (Object Information Repository)
of either a *PGM or a *MODULE object?

The OIR was architected way back when in CPF on the S/38, and
its basic format and layout has not been updated much since then.

The real problem with all these IFS path names is that the path can
contain an arbitrary number of "levels" of subdirectory, before you
even get to the actual file name, which in and of itself can be very
long... the architected "limit", by the way, if you can call it that, for
IFS path names in OS/400 is 16 Megabytes! (16 million+ characters)

Unix weenies in the Unix world rely on "naming conventions"
to find the corresponding source file for a given executable file.
Crude utilities like "make" rely on the file date/time stamps, using
the file system as a primitive database, to determine what changed,
and hence, what objects need to be recreated from "corresponding"
(by name only) source files.

Why must we drag OS/400 down to this same level of functionality
(the "lowest common denominator") in the name of strict Unix or
Posix compatibility? Ugh!

Just my opinion,

Mark S. Waterbury

----- Original Message -----
From: <rob@dekko.com>
To: <midrange-l@midrange.com>
Cc: <rpg400-l@midrange.com>
Sent: Wednesday, October 16, 2002 3:45 PM
Subject: RE: V5R2: Source now allowed in the IFS


> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> (pmr opened on compile issue, they can duplicate, rerunning the command
> works)
>
> If I use this command to compile from the IFS:
> CRTBNDRPG PGM(ROB/AAXYZ) SRCSTMF('/rob/aa.rpgle')
>
> On this program:
> ....+....1....+....2....+....3....+....4....
>  ************Beginning of data**************
>       /DEFINE HSpec
>       /COPY ROUTINES/QRPGLESRC,HSPEC
>       /UNDEFINE HSpec
>       /copy /rob/aa2.rpgle
>
>       /DEFINE DSpec
>       /COPY ROUTINES/QRPGLESRC,SRVPGMCPY
>      D* Your D specs ...
>       /UNDEFINE DSpec
>
>      C/FREE
>        *INLR=*ON;
>       /END-FREE
>  ************End of Data********************
>
> Then I do a DSPPGM of ROB/AAXYZ, I see:
>
> Oh crud, methinks they are missing something here!
>
> Program  . . . . . . . :   AAXYZ         Library  . . . . . . . :   ROB
>
> Module attributes:
>   Module . . . . . . . . . . . . . . . . . . . . :   AAXYZ
>     Library  . . . . . . . . . . . . . . . . . . :     QTEMP
>   Source file  . . . . . . . . . . . . . . . . . :
>     Library  . . . . . . . . . . . . . . . . . . :
>   Source member  . . . . . . . . . . . . . . . . :
>
> I also checked the API QBNLPGMI and there's nothing in there.  PMR is
> opened.  They were wondering when DSPPGM, and the API, will catch up.  I
> was told that C had the ability to compile from IFS for some time now.
>
> Now that the RPG people are using this, and are probably more prone to
> DSPPGM, then maybe this will get fixed.
>
>
> Rob Berendt
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.