Re: Yet Another ILE RPG Enhancement!

Thanks Hans.

To implement this may I suggest the following:

CRTDTAATA  DTAARA(QRPGLE/DFTLEHSPEC) TYPE(*CHAR) LEN(100) 
           VALUE('OPTION(*SRCSTMT *NODEBUGIO)') 
           TEXT('SYSTEM DEFAULT H-SPEC KEYWORDS')

By creating this data area, you will NOT have to code the keywords in your
H-specs for each program.

>Greetings RPG fans!  A few months ago when discussing the new stuff
>in the upcoming release of ILE RPG, I promised one more surprise
>enhancement.  Well, it's actually two:
>1) OPTION(*SRCSTMT) tells the compiler to assign statement numbers
>   that match the SEU source sequence numbers.
>2) OPTION(*NODEBUGIO) ensures that when stepping through an RPG
>   program in debug, you don't stop on all of the input or output
>   specs on an I/O operation.
>
>These features were so frequently requested, that we are providing
>these new features in PTFs for all releases back to V3R2.
>
>Note that you have to code an H spec keyword to get the new behaviour:
>          OPTION(*SRCSTMT *NODEBUGIO).
>In a release after V4R2, you'll be able to get the behaviour through
>the OPTION parameter on the command (the H spec keyword will still
>be available too).
>
>PTFs are available now for V3R2, V3R6, V3R7 and V4R2 that address the
>problem.  Currently the PTFs only fix TGTRLS(*CURRENT) - the other
>TGTRLS PTFs will be available soon.
>
>         Compiler (product 57xxRG1) | Runtime (product 57xxSS1)
>         -------------------------- | ------------------------
> V3R2    SF46001                    | SF45788
> V3R6    SF45749                    | SF45430
> V3R7    SF46327                    | SF46321
> V4R1    (use V3R7 compiler + PTF)  | SF46462
> V4R2    SF45191                    | SF45189
>
>Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
>
>---------------- Problem description ---------------------
>
>An ILE RPG program encounters an error during runtime.  The
>message indicates the source listing line number rather than
>the SEU source statement number.
>
>The user had to recompile the program to generate a compile
>listing to determine what line number was failing.  When
>executing the OPM version of their program the sequence number
>from the source member was listed in the error message.
>
>Another problem is that during debug, stepping on a READ or
>WRITE operation causes the debugger to step through I and
>O specifications rather than going directly to the statement
>after the READ or WRITE.
>
>----------------------- Answer ---------------------------
>
>The OPTION keyword is added to the Control specification.  The
>possible parameters are *SRCSTMT and *NODEBUGIO.  To specify
>both parameters, separate them with a colon.
>   OPTION(*SRCSTMT : *NODEBUGIO)
>
>In V4R2M0 where the OPTION keyword is already available, the
>new parameters for the OPTION keyword are *SRCSTMT, *NOSRCSTMT,
>*DEBUGIO, *NODEBUGIO.  *NOSRCSTMT and *DEBUGIO are the default.
>
>In a later release, the OPTION parameter of the CRTBNDRPG and
>CRTRPGMOD commands will be changed to add *SRCSTMT, *NOSRCSTMT,
>*DEBUGIO and *NODEBUGIO.  Also, in a later release, the syntax
>checker will be changed to accept the new keyword and these
>new parameter values.
>
>If keyword OPTION(*NODEBUGIO) is specified on the control
>specification, break points will not be generated for any
>input or output specifications.
>
>If keyword OPTION(*SRCSTMT) is specified on the control
>specification, statement numbers will be derived from the
>sequence number of the source file.  For example, line 000200
>in the main source member will have a statement number of
>000200.  This is the number that will appear in the listing,
>in the debugger and in exception messages.
>
>Source lines from /COPY members will have a statement number
>beginning with the source number (this number appears on the
>right side of the listing) followed by the six digits of the
>sequence number.  For example, line 001300 in /COPY member 23
>would have a statement number of 23001300.  On the left-hand
>side of the listing this would appear as 001300+ with the 23
>in the source Id columns on the right-hand side of the listing.
>23001300 would be the number that the debugger and exception
>messages would use.
>
>Similarly, generated lines for input and output specifications
>from externally described files will have a statement numbers
>derived from the source number and the sequence number.  In
>this case, the sequence number is assigned sequentially by
>the compiler for each record.
>
>Diagnostic messages in the compiler normally list the
>statement number and the sequence number.  If OPTION(*SRCSTMT)
>is specified, the entire statement number will be shown
>instead.
>   200+C                   scan      'a'           r
>======>      aaaaaaaaaaaaaa
>*RNF5009 30 a     1000200  Factor 1 entry is required...
>
>          A d d i t i o n a l   D i a g n o s t i c
> Msg id  Sv Number Seq     Message text
>*RNF7067 20        010300  Factor 1 or Factor 2 of PARM ...
>                           Field; defaults to blanks.
>*RNF7045 30      23000100  The field FLD on the C specificat...
>
>In the statement number fields of the program status data
>structure (PSDS) and file information data structure (INFDS),
>only eight digits are available.  If a statement number is
>longer than 6 digits, only the last 6 digits will be included.
>The first two characters will be set to '+ ' to indicate that
>the statement number was too large.  For example, statement
>123000100 will appear as '+ 000100'.  The first 4 digits of
>the statement number will be given in a different subfield
>as a 2-byte integer number (5I 0).
>
>     Location of statement number | Location of first 4 digits
>     -----------------------------+---------------------------
>     PSDS columns 21 - 28         | PSDS columns 354 - 355
>     PSDS columns 228 - 235       | PSDS columns 356 - 357
>     INFDS columns 30 - 37        | INFDS columns 77 - 78
>
>If you specify OPTION(*SRCSTMT), the breakpoints at the
>beginning and end of the source that are normally given
>statement numbers 1000001 and 1000002 will be given statement
>numbers 2100000001 and 2100000002.
>
>+---
>| 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 MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---
>
>


Charlie Massoglia, Massoglia Technical Consulting, Inc.
PO Box 1065, Okemos, MI 48854, USA
517-676-9700  Fax: 517-676-1006  EMAIL: cmassoglia@voyager.net


+---
| 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 MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---