Code Comments
Programming Forum and web based access to our favorite programming groups.
IBM S/390 memory model amd COBOLHello all, I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a client. Now it's testing time and our client has a problem which I thought of sharing with you. I'm not a COBOL programmer, but as you, I am capable of reading the algorithm. This piece of code has a bug on line 35 and 36 (at least one...). 01 77 SUB1 PIC 9(03) VALUE ZERO. 02 77 SUB2 PIC 9(03) VALUE ZERO. 03 77 SUB3 PIC 9(03) VALUE ZERO. 04 01 WK-NAME. 05 03 WK-NAME1 PIC X(35) VALUE SPACES. 06 03 WK-NAME2 PIC X(35) VALUE SPACES. 07 01 TABELA-NAME VALUE SPACES. 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES. 09 01 WK-NAME-1 VALUE SPACES. 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES. 11 01 WK-NAME-2 VALUE SPACES. 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES. 13 *----------------------------------------------------------------- 14 R030-ANALIZE-NAME. 15 PERFORM VARYING SUB1 FROM 60 BY -1 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1 17 END-PERFORM 18 IF SUB1 < 36 19 MOVE TABELA-NAME TO WK-NAME 20 ELSE 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES) 22 MOVE TABELA-NAME TO WK-NAME 23 ELSE 24 PERFORM VARYING SUB1 FROM 35 BY -1 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21 26 END-PERFORM 27 IF SUB1 < 21 28 MOVE TABELA-NAME TO WK-NAME 29 ELSE 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2) 32 END-PERFORM 33 MOVE 1 TO SUB3 34 ADD 1 TO SUB1 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3) 37 ADD 1 TO SUB3 38 END-PERFORM 39 MOVE WK-NAME-1 TO WK-NAME1 40 MOVE WK-NAME-2 TO WK-NAME2 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2. My question is: since the SUB3 goes beyond 35 in some cases of TAB-NAME, it gives me segmentation fault on Unix. The client says it runs well on OS390 but I cannot test this on OS390. Does this mean that it has no memory protection? Does OS390 and specially IBM COBOL allow for you to access memory locations randomly and outside your declared size for the variable? Thanks in advance. Paulo Ribeiro
Post Follow-up to this message
Re: IBM S/390 memory model amd COBOLSo far as I know, neither the '74 nor the '85 standard specifies what happens if an index or subscript is outside the range permitted by the associated OCCURS clause. Some implementors have options that strictly enforce index and subscript values at run time, some don't. Code that inadvertently or deliberately capitalizes on the ability to index or subscript outside the array is inherently nonportable. ISO/IEC 1989:2005 provides that the fatal EC-BOUND-SUBSCRIPT exception condition is set to exist whenever a subscript is out of range on a reference, or an attempt is made to set an index to a value that is out of range. -Chuck Stevens <ribjopabra@gmail.com> wrote in message news:1116427414.131266.308300@o13g2000cwo.googlegroups.com... > Hello all, > > I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a > client. > Now it's testing time and our client has a problem which I thought of > sharing with you. > I'm not a COBOL programmer, but as you, I am capable of reading the > algorithm. > This piece of code has a bug on line 35 and 36 (at least one...). > 01 77 SUB1 PIC 9(03) VALUE ZERO. > 02 77 SUB2 PIC 9(03) VALUE ZERO. > 03 77 SUB3 PIC 9(03) VALUE ZERO. > 04 01 WK-NAME. > 05 03 WK-NAME1 PIC X(35) VALUE SPACES. > 06 03 WK-NAME2 PIC X(35) VALUE SPACES. > 07 01 TABELA-NAME VALUE SPACES. > 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES. > 09 01 WK-NAME-1 VALUE SPACES. > 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES. > 11 01 WK-NAME-2 VALUE SPACES. > 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES. > 13 > *----------------------------------------------------------------- > 14 R030-ANALIZE-NAME. > 15 PERFORM VARYING SUB1 FROM 60 BY -1 > 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1 > 17 END-PERFORM > 18 IF SUB1 < 36 > 19 MOVE TABELA-NAME TO WK-NAME > 20 ELSE > 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES) > 22 MOVE TABELA-NAME TO WK-NAME > 23 ELSE > 24 PERFORM VARYING SUB1 FROM 35 BY -1 > 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21 > 26 END-PERFORM > 27 IF SUB1 < 21 > 28 MOVE TABELA-NAME TO WK-NAME > 29 ELSE > 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1 > 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2) > 32 END-PERFORM > 33 MOVE 1 TO SUB3 > 34 ADD 1 TO SUB1 > 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60 > 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3) > 37 ADD 1 TO SUB3 > 38 END-PERFORM > 39 MOVE WK-NAME-1 TO WK-NAME1 > 40 MOVE WK-NAME-2 TO WK-NAME2 > 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2. > > My question is: since the SUB3 goes beyond 35 in some cases of > TAB-NAME, it gives me segmentation fault on Unix. The client says it > runs well on OS390 but I cannot test this on OS390. Does this mean that > it has no memory protection? > > Does OS390 and specially IBM COBOL allow for you to access memory > locations randomly and outside your declared size for the variable? > > Thanks in advance. > > Paulo Ribeiro >
Post Follow-up to this message Re: IBM S/390 memory model amd COBOLIn article <1116427414.131266.308300@o13g2000cwo.googlegroups.com>,
ribjopabra@gmail.com <ribjopabra@gmail.com> wrote:
[snip]
>Does OS390 and specially IBM COBOL allow for you to access memory
>locations randomly and outside your declared size for the variable?
It used to be that in the Oldene Dayse before OS390 - ahhhhh, for the
Oldene Dayse, when a coder could code code such as *ten* coders cannot,
today! - some folks would depend on just this possibility to create and
address WORKING-STORAGE tables ('arrays') greater than 32K.
DD
Post Follow-up to this message Re: IBM S/390 memory model amd COBOLHi, DEC COBOL has the /CHECK=(BOUNDS) compiler qualifier. Normally, for debugging, you have it on. When you ship an image for production performance you can take it off. Regards Richard Maher <ribjopabra@gmail.com> wrote in message news:1116427414.131266.308300@o13g2000cwo.googlegroups.com... > Hello all, > > I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a > client. > Now it's testing time and our client has a problem which I thought of > sharing with you. > I'm not a COBOL programmer, but as you, I am capable of reading the > algorithm. > This piece of code has a bug on line 35 and 36 (at least one...). > 01 77 SUB1 PIC 9(03) VALUE ZERO. > 02 77 SUB2 PIC 9(03) VALUE ZERO. > 03 77 SUB3 PIC 9(03) VALUE ZERO. > 04 01 WK-NAME. > 05 03 WK-NAME1 PIC X(35) VALUE SPACES. > 06 03 WK-NAME2 PIC X(35) VALUE SPACES. > 07 01 TABELA-NAME VALUE SPACES. > 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES. > 09 01 WK-NAME-1 VALUE SPACES. > 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES. > 11 01 WK-NAME-2 VALUE SPACES. > 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES. > 13 > *----------------------------------------------------------------- > 14 R030-ANALIZE-NAME. > 15 PERFORM VARYING SUB1 FROM 60 BY -1 > 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1 > 17 END-PERFORM > 18 IF SUB1 < 36 > 19 MOVE TABELA-NAME TO WK-NAME > 20 ELSE > 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES) > 22 MOVE TABELA-NAME TO WK-NAME > 23 ELSE > 24 PERFORM VARYING SUB1 FROM 35 BY -1 > 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21 > 26 END-PERFORM > 27 IF SUB1 < 21 > 28 MOVE TABELA-NAME TO WK-NAME > 29 ELSE > 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1 > 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2) > 32 END-PERFORM > 33 MOVE 1 TO SUB3 > 34 ADD 1 TO SUB1 > 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60 > 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3) > 37 ADD 1 TO SUB3 > 38 END-PERFORM > 39 MOVE WK-NAME-1 TO WK-NAME1 > 40 MOVE WK-NAME-2 TO WK-NAME2 > 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2. > > My question is: since the SUB3 goes beyond 35 in some cases of > TAB-NAME, it gives me segmentation fault on Unix. The client says it > runs well on OS390 but I cannot test this on OS390. Does this mean that > it has no memory protection? > > Does OS390 and specially IBM COBOL allow for you to access memory > locations randomly and outside your declared size for the variable? > > Thanks in advance. > > Paulo Ribeiro >
Post Follow-up to this message Re: IBM S/390 memory model amd COBOLThat's it! With NOBOUND directive I can ommit this ugly "feature" and the COBOL runs fine. Thank you very much! Regards, Paulo Ribeiro
Post Follow-up to this message Re: IBM S/390 memory model amd COBOLI know that you have already received the BOUND/NOBOUND answer, but I though t I would reply with a couple of comments: 1) Current IBM COBOL has an SSRANGE option which will detect "out-of-bounds" subscripts. 2) For older (OS/VS COBOL) programs, the 3rd party CA-OPTIMIZER (aka "CAPEX" ) also had a subscript checker. 3) The interesting (to me) issue with the ISO 2002 EC-BOUND-SUBSCRIPT condit ion is that it *requires* checking for each level of a multi-level table being correct - even if the "combination" leaves an item within a table, e.g. 05 Tabl. 10 Level-1 Occurs 10 times. 15 Level-2 Occurs 5 Times. 20 Elem Pic X. Move "x" to Elem (1 6) raises an EC-BOUND-SUBSCRIPT condition. However, neither the Micro Focus BOUND/NOBOUND nor the IBM SSRANGE will have any problem with this. I do not know what other vendors do with their (optional) '85 Standard detection facilities. 4) One *SHOULD* write code to check for subscripts out-of-range and NOT "rel y" on NOBOUND, NOSSRANGE, etc techniques. As you see, these are not portable a nd MAY change in a future release of your current compiler. -- Bill Klein wmklein <at> ix.netcom.com <ribjopabra@gmail.com> wrote in message news:1116427414.131266.308300@o13g2000cwo.googlegroups.com... > Hello all, > > I'm migrating IBM COBOL (OS390, DB2) to MF COBOL (HPUX, ORACLE) for a > client. > Now it's testing time and our client has a problem which I thought of > sharing with you. > I'm not a COBOL programmer, but as you, I am capable of reading the > algorithm. > This piece of code has a bug on line 35 and 36 (at least one...). > 01 77 SUB1 PIC 9(03) VALUE ZERO. > 02 77 SUB2 PIC 9(03) VALUE ZERO. > 03 77 SUB3 PIC 9(03) VALUE ZERO. > 04 01 WK-NAME. > 05 03 WK-NAME1 PIC X(35) VALUE SPACES. > 06 03 WK-NAME2 PIC X(35) VALUE SPACES. > 07 01 TABELA-NAME VALUE SPACES. > 08 03 TAB-NAME PIC X(01) OCCURS 60 TIMES. > 09 01 WK-NAME-1 VALUE SPACES. > 10 03 WK-NAME-11 PIC X(01) OCCURS 35 TIMES. > 11 01 WK-NAME-2 VALUE SPACES. > 12 03 WK-NAME-21 PIC X(01) OCCURS 35 TIMES. > 13 > *----------------------------------------------------------------- > 14 R030-ANALIZE-NAME. > 15 PERFORM VARYING SUB1 FROM 60 BY -1 > 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1 > 17 END-PERFORM > 18 IF SUB1 < 36 > 19 MOVE TABELA-NAME TO WK-NAME > 20 ELSE > 21 IF (TAB-NAME(35) = SPACES OR TAB-NAME(36) = SPACES) > 22 MOVE TABELA-NAME TO WK-NAME > 23 ELSE > 24 PERFORM VARYING SUB1 FROM 35 BY -1 > 25 UNTIL TAB-NAME(SUB1) = SPACES OR SUB1 < 21 > 26 END-PERFORM > 27 IF SUB1 < 21 > 28 MOVE TABELA-NAME TO WK-NAME > 29 ELSE > 30 PERFORM VARYING SUB2 FROM 1 BY 1 UNTIL SUB2>SUB1 > 31 MOVE TAB-NAME(SUB2) TO WK-NAME-11(SUB2) > 32 END-PERFORM > 33 MOVE 1 TO SUB3 > 34 ADD 1 TO SUB1 > 35 PERFORM VARYING SUB2 FROM SUB1 BY 1 UNTIL SUB2>60 > 36 MOVE TAB-NAME(SUB2) TO WK-NAME-21(SUB3) > 37 ADD 1 TO SUB3 > 38 END-PERFORM > 39 MOVE WK-NAME-1 TO WK-NAME1 > 40 MOVE WK-NAME-2 TO WK-NAME2 > 41 MOVE SPACES TO WK-NAME-1 WK-NAME-2. > > My question is: since the SUB3 goes beyond 35 in some cases of > TAB-NAME, it gives me segmentation fault on Unix. The client says it > runs well on OS390 but I cannot test this on OS390. Does this mean that > it has no memory protection? > > Does OS390 and specially IBM COBOL allow for you to access memory > locations randomly and outside your declared size for the variable? > > Thanks in advance. > > Paulo Ribeiro >
Post Follow-up to this message Re: IBM S/390 memory model amd COBOL> With NOBOUND directive I can ommit this ugly "feature" and the COBOL > runs fine. That may stop the program failing but it does not make it run 'fine' nor even the same as the original code. When 01 records are compiled there is no guarantee that they will be continuous in the memory of the resulting program nor that they will have any particular spatial relationship. It is likely that on the original machine the two followed each other in memory with just a single slack byte between. On some machines the various 01 levels might not even be in the same memory segments. On others it may be that additional variables or literal are put between the 01 levels. In particular some compilers, even if they put all 01s in the same memory area, will place the 01 levels on 8 byte boundaries which would put a 5 slack bytes between the two areas in question. My best guess at the code is that it is dropping character 36 when this is not space. The results are likely to be wrong. You will be dropping an extra 4 characters of the text. Allowing a program to overwrite random data items outside the defined areas is danderous and foolish. The BOUND check is there for a reason, to stop programmers making mistakes and to ensure that the program is reliable. Also: this is the wrong way around: 15 PERFORM VARYING SUB1 FROM 60 BY -1 16 UNTIL TAB-NAME(SUB1) NOT = SPACES OR SUB1 < 1 17 END-PERFORM It should be: 16 UNTIL SUB1 < 1 OR TAB-NAME(SUB1) NOT = SPACES Cobol will 'short circuit the test'. If SUB1 becomes zero the latter version will result in TRUE before using a zero subscript. The version in your code will fail when TableA-Name is all spaces because the zero subscript will give a bound failure.
Post Follow-up to this message Re: IBM S/390 memory model amd COBOL> continuous in the memory Should be 'contiguous' (obviously).
Post Follow-up to this message Re: IBM S/390 memory model amd COBOL"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:y5Mie.273464$QY2.199422@fe01.news.easynews.com... > I know that you have already received the BOUND/NOBOUND answer, but I thought I > would reply with a couple of comments: > > 1) Current IBM COBOL has an SSRANGE option which will detect "out-of-bounds" > subscripts. Meaning.. "at runtime".. and your DUMP will tell even you the name of the table upon which you have sinned - VERY handy.. BUT..... From Experience: Using this option is an absolute performance KILLER. Suggest you use ONLY to debug, then recompile without this option for production after you've fixed your program. MCM .
Post Follow-up to this message Re: IBM S/390 memory model amd COBOLRichard, Thanks for your help. I agree that memory is a delicate matter. I am not the programmer here, I just deal with portability/migrating the code. Thanks for your eye on that bug! I do not plan to recode the client's code :) Regards
Post Follow-up to this message
Sponsored Links
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.
