Tweet
Re: Change opcodes to free format
And Rocky, keep kicking that carcass, amazing what gems will drop out.
Chris...
And Rocky, keep kicking that carcass, amazing what gems will drop out.
Chris...
-
-
Re: Change opcodes to free format
Oh yeah, it's definitely cumbersome to deal with in SEU!! Hopefully it goes without saying that RDi would be a better choice?Comment
-
Re: Change opcodes to free format
SEU only accepts a maximum record length of 240 characters:-( So if you need to maintain some level of access with SEU (emergency updates) make sure you keep the record length below that. I would think 150 would be more than enough :-)...
Chris...Comment
-
Re: Change opcodes to free format
A (minor) favorite personal enjoyment of mine is reading discussions of how great it is to have long names, lines, expressions, etc., in RPG. What makes me chuckle is how the discussions have changed since the support became available.
Not too many years ago (before availability), discussions commonly included defense of short names and short expressions, as well as no need for D-specs. Comments were usually framed in terms of how terrible COBOL was because of its wordiness. Now it's almost possible to write the same programming in the two languages and have them look recognizably equivalent. (I suspect it'd be fairly easy to write a translator between the two.)
Now, discussions might be framed in terms of "Isn't it great that we can make RPG as wordy as COBOL?"
How times have changed.Tom
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?Comment
-
Re: Change opcodes to free format
LOL - though it would be tough to make RPG as wordy as COBOL... 13 lines of code just to display "Hello World" verses what - 2? In regards to translator when I was in college (1980) the college I went to had CDC computers. CDC didn't have an RPG compiler - they had a translator that would translate the RPG code to COBOL and they wanted $12,000/month for this... rather than pay such exhorbitant prices they contracted a Jr college to take the RPG code and compile them. So those of us who had to learn RPG they sent the code to a 2 yr college twice a day - they'd compile the RPG code and send back the listing - basically had 2 shots a day so make them count! Memories.... LOLComment
-
Re: Change opcodes to free format
I just had to do this yesterday... I made a srcpf with a record length of 240 in order to hold a source with long FTP commands since IBM i doesn't support line-wrapping in FTP.I am absolutely gob-smacked, I always create the source file with a record length of 92 as that was the default, never even considered creating one with longer records!!!Comment
-
Re: Change opcodes to free format
It can be done in 2 lines in COBOL in fairly recent compilers on i (V5R3 is earliest I can test). One line is pure "boiler-plate" as is half of the second line. Anything that's 'boiler-plate' can be part of a template and practically ignored.Originally posted by Rocky View Post
It might be possible to get more characters removed. That was far enough for me. But I'm not sure how 'absolute minimum' code is particularly relevant when the discussion context is about how coding can include longer lines, identifiers and expressions. (REXX takes 17 characters on a single source line.)Code:ID Division. Environment Division. Data Division. Procedure Division. display "Hello, World" .Tom
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?Comment
-
Re: Change opcodes to free format
While I accept that something larger than 80 might be useful on occasion, do you _really_ want no limit? Seems to me the only thing that would guarantee is that sooner or later I'd end up have to maintain code that some bozo decided should be a 500+ completely unmaintainable mess.Originally posted by DAG0000 View PostComment
-
Re: Change opcodes to free format
Originally posted by JonBoy View Post
John, we are already getting an unreadable mess with free form on the D-Specs, from what I have been seeing. D and F specs are the one place where some form of fixed placement is beneficial as to reading the code. As for the column limit, it should be long enough (if there is to be one) to make the use of long fields name feasible without having to break up the linesComment
-
Re: Change opcodes to free format
It's been awhile since I coded COBOL to be sure - but you did put essentially five lines of code... SEU complains profusely but it does compile. Which is a marked improvement of COBOL of old.... contrast that with:Originally posted by tomliotta View Post
Code:DSPLY 'Hello world'; *INLR = *ON;
Comment
-
Re: Change opcodes to free format
I don't personally find that folks make any more of a mess with free-form Ds and Fs than they do if calcs. Personally I have adopted some coding standards that work for me without being arduous and requiring a fixed columnar alignment. I also discussed with the folks at Linoma the possibility of providing some additional controls over the formatting of converted D & F by their Toolbox.Originally posted by DAG0000 View Post
I have no issues with increasing the line length - just like to see some limit that stops the real idiots in their tracks. But what is "big enough"? For me I feel I only need another 20 or so, so extending to 132 would probably be enough - but I know others would disagree.Comment
-
Re: Change opcodes to free format
Interesting - the very thing that you argue for longer column length - use of long field names without having to break up the lines - is EXACTLY what the free format D specs are put there to accomplish... use of long fields names without having to use ellipsis (...) and breaking up the lines to use long field names... and IMO it makes them more readable anyway.John, we are already getting an unreadable mess with free form on the D-Specs, from what I have been seeing. D and F specs are the one place where some form of fixed placement is beneficial as to reading the code. As for the column limit, it should be long enough (if there is to be one) to make the use of long fields name feasible without having to break up the lines
Verses:Code:E***************************************************************** E** TABLES & ARRAYS E***************************************************************** E TABPCT 6 6 1 0 TABVAL 2 2 VALUATION PERC. E TABMO 12 12 2 0 TABDYS 2 0 #Days/Month E @A 1 1 78 DSP APP. TITLE E @TC 1 11 78 COMP TITLES E @F 1 10 78 DSP FOOTERS E @E 1 41 69 DSP ERRORS E @O 1 6 80 OVERRIDES/CMDS E @M 1 4 80 MISC TEXT E @VT 9 9 3 VALID TYPE CODES E @C 4 2 SCREEN CODES E @MC 3 2 MISC CODES E @MV 3 7 0 MISC FEES E @W 50 1 WORK ARRAY E @S 125 1 STRING E @D 3 8 0 DATES 30 60 90 E @T 11 78 DSP TITLES E @P 7 1 LIC. #
A whole lot easier to see what is coded...Code://**************************************************************** //* TABLES & ARRAYS //**************************************************************** DCL-S TABPCT PACKED(1) DIM(6) CTDATA PERRCD(6); // VALUATION PERC. DCL-S TABVAL PACKED(2:2) DIM(6) ALT(TABPCT); DCL-S TABMO PACKED(2) DIM(12) CTDATA PERRCD(12); // #DAYS/MONTH DCL-S TABDYS PACKED(2) DIM(12) ALT(TABMO); DCL-S @A CHAR(78) DIM(1) CTDATA PERRCD(1); // DSP APP. TITLE DCL-S @TC CHAR(78) DIM(11) CTDATA PERRCD(1); // COMP TITLES DCL-S @F CHAR(78) DIM(10) CTDATA PERRCD(1); // DSP FOOTERS DCL-S @E CHAR(69) DIM(41) CTDATA PERRCD(1); // DSP ERRORS DCL-S @O CHAR(80) DIM(6) CTDATA PERRCD(1); // OVERRIDES/CMDS DCL-S @M CHAR(80) DIM(4) CTDATA PERRCD(1); // MISC TEXT DCL-S @VT CHAR(3) DIM(9) CTDATA PERRCD(9); // VALID TYPE CODES DCL-S @C CHAR(2) DIM(4); // SCREEN CODES DCL-S @MC CHAR(2) DIM(3); // MISC CODES DCL-S @MV PACKED(7) DIM(3); // MISC FEES DCL-S @W CHAR(1) DIM(50); // WORK ARRAY DCL-S @S CHAR(1) DIM(125); // STRING DCL-S @D PACKED(8) DIM(3); // DATES 30 60 90 DCL-S @T CHAR(78) DIM(11); // DSP TITLES DCL-S @P CHAR(1) DIM(7); // LIC. #
Even more mundane:
Is basically clear for us "old timers" - butCode:IWSDS DS I 369 369 KEY I 370 370 ROW I 371 371 COL I B 370 3710CURSOR
Code://**************************************************************** //* WORK STATION CONTROLS //**************************************************************** DCL-DS Wsds; Key CHAR(1) POS(369); Cursor BINDEC(4); Row CHAR(1) OVERLAY(Cursor); Col CHAR(1) OVERLAY(Cursor:2); END-DS;Code:DCL-PI MVR060; Sysmo PACKED(2); // Real (True) Sysdy PACKED(2); // System Sysyr PACKED(2); // Date END-PI;Code:C PARM SYSMO 20 Real (True) C PARM SYSDY 20 System C PARM SYSYR 20 Date
Yes - it's clear isn't it that these three fields are 2 digits Packed Decimal? Maybe they're 20 characters... can't tell at first glance without first having to know the #$@$@$OLIJK@:$ columns. The former is painfully clear - the latter is cryptic - even if you were to move them up into a DS isn't a whole lot better...
Code:I DS I P 1 50FIELD1 I P 6 100FIELD2 I P 11 162FIELD3 I 17 202FIELD4Code:DCL-DS *N; FIELD1 PACKED(9); FIELD2 PACKED(9); FIELD3 PACKED(9:2); FIELD4 ZONED(4:2); END-DS;
The first one for us "old timers" is readable enough - but the latter is far more communicative - 3 packed decimals showing the actual # of digits - no need to multiply by 2 and subtract 1 to know how big the field is - and it's obviously Packed Decimal (the latter is dependant - it's packed in the PARM but ZONED in I specs if not explicitely told otherwise). And the latter is Zone Decimal... and technically more accurate as 9 digits fit in 5 bytes.
Then we get into fixed format D specs... essentially the same as above... with one more caveat:
Code:D DS D FIELD1 1 5P 0 D FIELD2 6 10P 0 D FIELD3 11 15P 2 D FIELD4 4 0 D LETSTRYTHISONFORSIZE... D 5 0 D LETSTRYTHISONFORSIZENUMBER2... D 5 0 D FIELD5 5 0 D FIELD6 5 0 D LETSTRYTHISONFORSIZENUMBER3... D 5 0Which one is clearer? Widening the column length from 80 has it's merits - but I for one am glad for free format D specs..Code:DCL-DS *N; Field1 PACKED(9) POS(1); Field2 PACKED(9) POS(6); Field3 PACKED(9:2) POS(11); Field4 ZONED(4); Letstrythisonforsize ZONED(5); Letstrythisonforsizenumber2 ZONED(5); Field5 ZONED(5); Field6 ZONED(5); Letstrythisonforzizenumber3 ZONED(5); END-DS;Last edited by Rocky; January 2, 2015, 10:54 AM.Comment
-
Re: Change opcodes to free format
Thought that since I'd mentioned the coding standard I am currently using that I would "translate" your example. I personally find it hard to read when the free-form refs are as "dense" as yours - hence the style I adopted. Each to his own but for what it is worth ...Originally posted by Rocky View Post
P.S. I didn't bother re-aligning your comments - but I'd have aligned them just beyond the longest line's ;
Code://**************************************************************** //* TABLES & ARRAYS //**************************************************************** DCL-S TABPCT PACKED(1) DIM(6) CTDATA PERRCD(6); // VALUATION PERC. DCL-S TABVAL PACKED(2:2) DIM(6) ALT(TABPCT); DCL-S TABMO PACKED(2) DIM(12) CTDATA PERRCD(12); // #DAYS/MONTH DCL-S TABDYS PACKED(2) DIM(12) ALT(TABMO); DCL-S @A CHAR(78) DIM(1) CTDATA PERRCD(1); // DSP APP. TITLE DCL-S @TC CHAR(78) DIM(11) CTDATA PERRCD(1); // COMP TITLES DCL-S @F CHAR(78) DIM(10) CTDATA PERRCD(1); // DSP FOOTERS DCL-S @E CHAR(69) DIM(41) CTDATA PERRCD(1); // DSP ERRORS DCL-S @O CHAR(80) DIM(6) CTDATA PERRCD(1); // OVERRIDES/CMDS DCL-S @M CHAR(80) DIM(4) CTDATA PERRCD(1); // MISC TEXT DCL-S @VT CHAR(3) DIM(9) CTDATA PERRCD(9); // VALID TYPE CODES DCL-S @C CHAR(2) DIM(4); // SCREEN CODES DCL-S @MC CHAR(2) DIM(3); // MISC CODES DCL-S @MV PACKED(7) DIM(3); // MISC FEES DCL-S @W CHAR(1) DIM(50); // WORK ARRAY DCL-S @S CHAR(1) DIM(125); // STRING DCL-S @D PACKED(8) DIM(3); // DATES 30 60 90 DCL-S @T CHAR(78) DIM(11); // DSP TITLES DCL-S @P CHAR(1) DIM(7); // LIC. #Last edited by JonBoy; January 2, 2015, 11:32 AM.Comment
-
Re: Change opcodes to free format
Rocky, take a look at the DCL-S examples you posted. That is somewhat readable since all of the field names are on 2-3 characters in length. Now change them so some are 1 or 2 characters and others are 10 or 15 and see what it looks like. That is a example of what I mean, and this is really about programmers formatting their code so its presentable and readable. Its no different then indenting if statements so I you can follow the flow of the code. Just because we can now write keywords in any part of the line doesn't mean we should just put them any where we like.
This is far easier to read then what you had posted.
Code:DCL-S TABPCT PACKED(1) DIM(6) CTDATA PERRCD(6); // VALUATION PERC. DCL-S TABVAL PACKED(2:2) DIM(6) ALT(TABPCT); DCL-S TABMO PACKED(2) DIM(12) CTDATA PERRCD(12); // #DAYS/MONTH DCL-S TABDYS PACKED(2) DIM(12) ALT(TABMO); DCL-S @A CHAR(78) DIM(1) CTDATA PERRCD(1); // DSP APP. TITLE DCL-S @TC CHAR(78) DIM(11) CTDATA PERRCD(1); // COMP TITLES DCL-S @F CHAR(78) DIM(10) CTDATA PERRCD(1); // DSP FOOTERS DCL-S @E CHAR(69) DIM(41) CTDATA PERRCD(1); // DSP ERRORS DCL-S @O CHAR(80) DIM(6) CTDATA PERRCD(1); // OVERRIDES/CMDS DCL-S @M CHAR(80) DIM(4) CTDATA PERRCD(1); // MISC TEXT DCL-S @VT CHAR(3) DIM(9) CTDATA PERRCD(9); // VALID TYPE CODES DCL-S @C CHAR(2) DIM(4); // SCREEN CODES DCL-S @MC CHAR(2) DIM(3); // MISC CODES DCL-S @MV PACKED(7) DIM(3); // MISC FEES
Comment
-
Re: Change opcodes to free format
I agree - in "real life" I spend more time in cleaning up the conversion - I just took what RPG Toolbox gave for purposes of illustration. What I was trying to communicate is that there is more information in free format that is clear than the cryptic column format of fixed format.Comment
Comment