variable length in REDEFINES
in [Cobol]
|
From: Frank Swarbrick on 15 Jul 2008 12:21 >>> On 7/12/2008 at 1:32 AM, in message <K6Zdk.222867$SV4.39057(a)bgtnsc04-news.ops.worldnet.att.net>, Arnold Trembley<arnold.trembley(a)worldnet.att.net> wrote: > Frank Swarbrick wrote: >> Can anyone give me a good reason why this copybook should give an error? >> >> 01 SQLLINK. >> 05 SQL-ERROR-INFO-IN PIC X(20). >> 05 REDEFINES SQL-ERROR-INFO-IN. >> 10 SQL-ERROR-ACTION PIC X. >> 05 SQL-ERROR-INFO-OUT PIC X(20). >> 05 REDEFINES SQL-ERROR-INFO-OUT. >> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3. >> 05 ERRLOC PIC X(60). >> 05 SQL-ERRLOC REDEFINES ERRLOC. >> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN. >> >> Here's what I get: >> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS > DEPENDING >> ON" >> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS >> DISCARDED. >> >> Now I'm not asking if it is in the standard or anything. I want to know >> *why*. It seems to me to be harmless, as long as the max occurance > doesn't >> make the redefine exceed the length of the field it is redefining, and > as >> long as there are no 05 levels following it. >> >> Not that it matters. If I can't do it then I can't do it. But it bugs > me! >> :-) >> >> Frank >> >> > > Frank, is this IBM COBOL on DOS/VSE or z/VSE? I'm not sure if that > should make any difference compared to Enterprise COBOL for z/OS. IBM COBOL for VSE/ESA 1.1.1. > I tried this with Realia COBOL 1.0 from 1990, and it only gave a > warning message "Variable length OCCURS accepted in REDEFINES". Interesting... > It seems odd to me that the level 10 data item that has OCCURS > DEPENDING ON has no data name, and therefore must default to FILLER. > How could you ever reference it? I don't need to reference the individual bytes. Just the SQL-ERRLOC name. See below for an example. > You might try changing it to look like this, just to see if you get a > different result: > > 05 ERRLOC PIC X(60). > 05 SQL-ERRLOC REDEFINES ERRLOC. > 10 SQL-ERRLOC-BYTE > OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN > PIC X. > > I'm not sure how having the ODO helps you, versus simply redefining > the ERRLOC field as a fixed-length array of 60 bytes. I know, seems like kind of a weird request. The reason I would like it is so I can do something like this: STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation.' DELIMITED BY SIZE INTO ERROR-MSG Without it I have to do: STRING 'SQL error in ' ERRLOC (1:SQL-ERRLOC-LEN) ' -- Consult documentation.' DELIMITED BY SIZE INTO ERROR-MSG Big deal? No. I just thought it would be nice if I could do the former. Frank
From: Frank Swarbrick on 15 Jul 2008 12:29 >>> On 7/12/2008 at 4:33 PM, in message <s5ci7419vkmvb998tujblo8tgrkarjp9bf(a)4ax.com>, Robert<no(a)e.mail> wrote: > On Fri, 11 Jul 2008 18:36:21 -0600, "Frank Swarbrick" > <Frank.Swarbrick(a)efirstbank.com> > wrote: > >>Can anyone give me a good reason why this copybook should give an error? >> >> 01 SQLLINK. >> 05 SQL-ERROR-INFO-IN PIC X(20). >> 05 REDEFINES SQL-ERROR-INFO-IN. >> 10 SQL-ERROR-ACTION PIC X. >> 05 SQL-ERROR-INFO-OUT PIC X(20). >> 05 REDEFINES SQL-ERROR-INFO-OUT. >> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3. >> 05 ERRLOC PIC X(60). >> 05 SQL-ERRLOC REDEFINES ERRLOC. >> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN. >> >>Here's what I get: >>IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS DEPENDING >>ON" >> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS >>DISCARDED. >> >>Now I'm not asking if it is in the standard or anything. I want to know >>*why*. It seems to me to be harmless, as long as the max occurance > doesn't >>make the redefine exceed the length of the field it is redefining, and as >>long as there are no 05 levels following it. >> >>Not that it matters. If I can't do it then I can't do it. But it bugs > me! >>:-) > > You don't need ERRLOC. Delete ERRLOC and the redefines clause. Actually I do. The intent is this: - ERRLOC is set by a calling routine to pass to a called routine. - the called routine, among doing other actual important things, determines the actual length of ERRLOC (sans trailing spaces) and sets SQL-ERRLOC-LEN to this value. - The calling routine, after getting control back from the called routine, now can use the value of SQL-ERRLOC-LEN. My hope was that it could use SQL-ERRLOC and not have to use reference modification to "trim" the ERRLOC field. Frank
From: Frank Swarbrick on 15 Jul 2008 12:37 Hi Bill. Do you realize that when you top-post and place your signature before that items that you quoted when some newsreaders (like mine) reply to you they cut off everything below the "-- "? Just an FYI. I didn't need to quote myself here, so it didn't matter. n 7/12/2008 at 5:56 PM, in message <_wbek.257015$qk1.34132(a)fe02.news.easynews.com>, William M. Klein<wmklein(a)nospam.netcom.com> wrote: > Frank, > You didn't ask how to "fix" this code, but (as I understand it) WHY > there was > such a restrction. Indeed, that was my question! I know of many ways to get around the restriction. I simply wanted to know why the restriction exists in the first place. > I don't recall this being dissussed (and I'll bet it has been in the > Standard > since '74 if not '68). However, my best GUESS would be that: > > Because the "object of the ODO" - SQL-ERRLOC-LEN - in this case MAY get > "out-of range" (greater than 60) during the exectuion of the program, > that this > mighr have been viewed as something to avoid at run-time (larger item > redefining > a smaller item - which has always been illegal - although some vendors > allow it > as an extension). I guess I don't see this as being any more or less likely than if I had done it this way: 01 SQLLINK. 05 SQL-ERROR-INFO-IN PIC X(20). 05 REDEFINES SQL-ERROR-INFO-IN. 10 SQL-ERROR-ACTION PIC X. 05 SQL-ERROR-INFO-OUT PIC X(20). 05 REDEFINES SQL-ERROR-INFO-OUT. 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3. 05 SQL-ERRLOC REDEFINES ERRLOC. 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN. > As I recall there was a difference introduce either in the '85 or '02 > Standards > as to when "out-of-range" ODO values were detected (and gave unpredictable > > results). At one time, these conditions were detected when the ODO > field was > "used" and at another time, it was detected when the ODO item was set. Hmmm. I'm not sure I understand this, but I don't know what it is I don't understand... > Again, this is just guessing. As the Standard explicitly allows a > smaller (or > same-size) field to redefine a "larger" (or same size) field, it would > LOOK to > me as if what have coded would make sense. Me too! And thus the question. > *** > > FYI, > Frank did NOT ask for it, but if anyone wants to know the relevant > "Standard" > rule it is (from the '02 Standard), > > "Neither the original definition nor the redefinition shall include a > variable-occurrence data item." Yuck! :-) I can understand the former, but I don't agree with the latter. Oh well... Frank
From: Pete Dashwood on 15 Jul 2008 21:34 "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote in message news:487C7A1D.6F0F.0085.0(a)efirstbank.com... >>>> On 7/12/2008 at 1:32 AM, in message > <K6Zdk.222867$SV4.39057(a)bgtnsc04-news.ops.worldnet.att.net>, Arnold > Trembley<arnold.trembley(a)worldnet.att.net> wrote: >> Frank Swarbrick wrote: >>> Can anyone give me a good reason why this copybook should give an error? >>> >>> 01 SQLLINK. >>> 05 SQL-ERROR-INFO-IN PIC X(20). >>> 05 REDEFINES SQL-ERROR-INFO-IN. >>> 10 SQL-ERROR-ACTION PIC X. >>> 05 SQL-ERROR-INFO-OUT PIC X(20). >>> 05 REDEFINES SQL-ERROR-INFO-OUT. >>> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3. >>> 05 ERRLOC PIC X(60). >>> 05 SQL-ERRLOC REDEFINES ERRLOC. >>> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN. >>> >>> Here's what I get: >>> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS >> DEPENDING >>> ON" >>> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS >>> DISCARDED. >>> >>> Now I'm not asking if it is in the standard or anything. I want to know >>> *why*. It seems to me to be harmless, as long as the max occurance >> doesn't >>> make the redefine exceed the length of the field it is redefining, and >> as >>> long as there are no 05 levels following it. >>> >>> Not that it matters. If I can't do it then I can't do it. But it bugs >> me! >>> :-) >>> >>> Frank >>> >>> >> >> Frank, is this IBM COBOL on DOS/VSE or z/VSE? I'm not sure if that >> should make any difference compared to Enterprise COBOL for z/OS. > > IBM COBOL for VSE/ESA 1.1.1. > >> I tried this with Realia COBOL 1.0 from 1990, and it only gave a >> warning message "Variable length OCCURS accepted in REDEFINES". > > Interesting... > >> It seems odd to me that the level 10 data item that has OCCURS >> DEPENDING ON has no data name, and therefore must default to FILLER. >> How could you ever reference it? > > I don't need to reference the individual bytes. Just the SQL-ERRLOC name. > See below for an example. > >> You might try changing it to look like this, just to see if you get a >> different result: >> >> 05 ERRLOC PIC X(60). >> 05 SQL-ERRLOC REDEFINES ERRLOC. >> 10 SQL-ERRLOC-BYTE >> OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN >> PIC X. >> >> I'm not sure how having the ODO helps you, versus simply redefining >> the ERRLOC field as a fixed-length array of 60 bytes. > > I know, seems like kind of a weird request. The reason I would like it is > so I can do something like this: > STRING 'SQL error in ' > SQL-ERRLOC > ' -- Consult documentation.' > DELIMITED BY SIZE > INTO ERROR-MSG > > Without it I have to do: > STRING 'SQL error in ' > ERRLOC (1:SQL-ERRLOC-LEN) > ' -- Consult documentation.' > DELIMITED BY SIZE > INTO ERROR-MSG > > Big deal? No. I just thought it would be nice if I could do the former. > What about... > STRING 'SQL error in ' > SQL-ERRLOC DELIMITED BY SIZE > ' -- Consult documentation.' > DELIMITED BY SIZE > INTO ERROR-MSG ....as a possible solution? Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 16 Jul 2008 00:19
On Wed, 16 Jul 2008 13:34:45 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >"Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote in message >news:487C7A1D.6F0F.0085.0(a)efirstbank.com... >>>>> On 7/12/2008 at 1:32 AM, in message >> <K6Zdk.222867$SV4.39057(a)bgtnsc04-news.ops.worldnet.att.net>, Arnold >> Trembley<arnold.trembley(a)worldnet.att.net> wrote: >>> Frank Swarbrick wrote: >>>> Can anyone give me a good reason why this copybook should give an error? >>>> >>>> 01 SQLLINK. >>>> 05 SQL-ERROR-INFO-IN PIC X(20). >>>> 05 REDEFINES SQL-ERROR-INFO-IN. >>>> 10 SQL-ERROR-ACTION PIC X. >>>> 05 SQL-ERROR-INFO-OUT PIC X(20). >>>> 05 REDEFINES SQL-ERROR-INFO-OUT. >>>> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3. >>>> 05 ERRLOC PIC X(60). >>>> 05 SQL-ERRLOC REDEFINES ERRLOC. >>>> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN. >>>> >>>> Here's what I get: >>>> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS >>> DEPENDING >>>> ON" >>>> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS >>>> DISCARDED. >>>> >>>> Now I'm not asking if it is in the standard or anything. I want to know >>>> *why*. It seems to me to be harmless, as long as the max occurance >>> doesn't >>>> make the redefine exceed the length of the field it is redefining, and >>> as >>>> long as there are no 05 levels following it. >>>> >>>> Not that it matters. If I can't do it then I can't do it. But it bugs >>> me! >>>> :-) >>>> >>>> Frank >>>> >>>> >>> >>> Frank, is this IBM COBOL on DOS/VSE or z/VSE? I'm not sure if that >>> should make any difference compared to Enterprise COBOL for z/OS. >> >> IBM COBOL for VSE/ESA 1.1.1. >> >>> I tried this with Realia COBOL 1.0 from 1990, and it only gave a >>> warning message "Variable length OCCURS accepted in REDEFINES". >> >> Interesting... >> >>> It seems odd to me that the level 10 data item that has OCCURS >>> DEPENDING ON has no data name, and therefore must default to FILLER. >>> How could you ever reference it? >> >> I don't need to reference the individual bytes. Just the SQL-ERRLOC name. >> See below for an example. >> >>> You might try changing it to look like this, just to see if you get a >>> different result: >>> >>> 05 ERRLOC PIC X(60). >>> 05 SQL-ERRLOC REDEFINES ERRLOC. >>> 10 SQL-ERRLOC-BYTE >>> OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN >>> PIC X. >>> >>> I'm not sure how having the ODO helps you, versus simply redefining >>> the ERRLOC field as a fixed-length array of 60 bytes. >> >> I know, seems like kind of a weird request. The reason I would like it is >> so I can do something like this: >> STRING 'SQL error in ' >> SQL-ERRLOC >> ' -- Consult documentation.' >> DELIMITED BY SIZE >> INTO ERROR-MSG >> >> Without it I have to do: >> STRING 'SQL error in ' >> ERRLOC (1:SQL-ERRLOC-LEN) >> ' -- Consult documentation.' >> DELIMITED BY SIZE >> INTO ERROR-MSG >> >> Big deal? No. I just thought it would be nice if I could do the former. >> > >What about... > >> STRING 'SQL error in ' >> SQL-ERRLOC > DELIMITED BY SIZE >> ' -- Consult documentation.' >> DELIMITED BY SIZE >> INTO ERROR-MSG > >...as a possible solution? No, it is exactly the same. A DELIMITED clause applies to all data names and literals left of it and right of the previous DELIMITED clause, if any. If there is no DELIMITED clause, SIZE is implied. Thus, these are the same: STRING A DELIMITED BY SIZE B DELIMITED BY SIZE C DELIMITED BY SIZE INTO ... STRING A B C DELIMITED BY SIZE INTO ... STRING A B C INTO ... Two spaces is a useful way to delimit strings lacking a length, as in Frank's case STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation. ' DELMITED BY ' ' *> literal is two spaces INTO ERROR-MSG Nervous programmers don't trust that technique out of fear the string might contain two spaces typed in by a user. OK, how about ten spaces? STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation. ' DELMITED BY ' ' *> literal is 10 spaces INTO ERROR-MSG They would rather feed the Cobol reputation for verbosity with this: MOVE 60 TO SQL-ERRLOC-LEN MOVE ZERO TO TEMP INSPECT FUNCTION REVERSED(SQL-ERRLOC) TALLYING TEMP FOR LEADING SPACE SUBTRACT TEMP FROM SQL-ERRLOC-LEN MOVE SPACES TO ERROR-MSG STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation. ' INTO ERROR-MSG A better way is EXEC SQL SELECT 'SQL error in ' TRIM(:SQL-ERRLOC) ' -- Consult documentation. ' INTO :ERROR-MSG FROM sysibm.sysdummy1 -- FROM DUAL on Oracle END-EXEC If using OpenESQL, TRIM() is superfluous because it automatically trims strings. A way to trim left spaces with a single statement is UNSTRING sloppy-word DELIMITED BY ALL SPACE INTO trimmed trimmed If it doesn't have a leading space, the first mention of trimmed is the destination. If it does have leading spaces, they go into the first mention of trimmed, only to be overwritten by the word going into the second mention of trimmed. |