variable length in REDEFINES
in [Cobol]
|
From: Robert on 16 Jul 2008 04:12 On Tue, 15 Jul 2008 23:19:26 -0500, Robert <no(a)e.mail> wrote: >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 Correction: EXEC SQL SELECT 'SQL error in || ' TRIM(:SQL-ERRLOC) || ' -- Consult documentation. '
From: Anonymous on 16 Jul 2008 05:39 In article <pupq74t94srcr2ps97vc6qikc24he4gq1u(a)4ax.com>, Robert <no(a)e.mail> wrote: [snip] >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. Inexperienced programmers may never never had a Corner Office Idiot come to their desks, slam down a Manhattan telephone-directory-sized (Yellow Pages, containing the business listings) and yowl about how error messages are getting mangled, truncated or distorted, either. >OK, how about ten spaces? > >STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation. ' > DELMITED BY ' ' *> literal is 10 spaces > INTO ERROR-MSG Inexperienced programmers may never have had a Corener Office Idiot summon them to receive a command to change the wording or composition of an error message under certain conditions (varying commodities prices, mid-day temperatures, number of birds on a window-ledge), complete with line-wrap and mixed-case formatting, and sent on their way with 'The email software does this all the time, there shouldn't be a problem... all ya gotta do is what they're doing'. > >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 I've never met a programmer who has professed a desire to do 'feed the Cobol reputation for verbosity', Mr Wagner... but I have, in my time, run across UseNet posters who has seemed to desire to impute motives to others so as to bolster an argument which degrades said others' abilities, efforts, approaches or solutions. DD
From: Frank Swarbrick on 16 Jul 2008 20:30 >>> On 7/15/2008 at 10:19 PM, in message <pupq74t94srcr2ps97vc6qikc24he4gq1u(a)4ax.com>, Robert<no(a)e.mail> wrote: > 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 I guess I am one of those 'nervous programmers'. If only Cobol had "DELIMITED BY TRAILING SPACES" or some such thing. > 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 Yep. This is essentially what I would do in the called program. > 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 Use SQL to do what Cobol should do? Interesting, but rediculous that it would be required. > 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. How about trimming right spaces? The best would be the proposed TRIM instrinsic function: STRING 'SQL error in ' FUNCTION TRIM(SQL-ERRLOC) ' -- Consult documentation.' DELIMITED BY SIZE INTO ERROR-MSG OpenCobol supports it! But VSE won't in my lifetime. Ah well! Frank
From: Robert on 16 Jul 2008 22:35 On Wed, 16 Jul 2008 09:39:30 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <pupq74t94srcr2ps97vc6qikc24he4gq1u(a)4ax.com>, >Robert <no(a)e.mail> wrote: > >[snip] > >>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. > >Inexperienced programmers may never never had a Corner Office Idiot come >to their desks, slam down a Manhattan telephone-directory-sized (Yellow >Pages, containing the business listings) and yowl about how error messages >are getting mangled, truncated or distorted, either. > >>OK, how about ten spaces? >> >>STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation. ' >> DELMITED BY ' ' *> literal is 10 spaces >> INTO ERROR-MSG > >Inexperienced programmers may never have had a Corener Office Idiot summon >them to receive a command to change the wording or composition of an error >message under certain conditions (varying commodities prices, mid-day >temperatures, number of birds on a window-ledge), complete with line-wrap >and mixed-case formatting, and sent on their way with 'The email software >does this all the time, there shouldn't be a problem... all ya gotta do is >what they're doing'. > >> >>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 > >I've never met a programmer who has professed a desire to do 'feed the >Cobol reputation for verbosity', Mr Wagner... but I have, in my time, run >across UseNet posters who has seemed to desire to impute motives to others >so as to bolster an argument which degrades said others' abilities, >efforts, approaches or solutions. You denigrate the manager by calling him a Corner Office Idiot. In the next sentence you say contracting is about doing the bidding of the one who signs your timecard, usually the same manager. Further, you imply that those who disagree should be stripped of their templates and drummed out of the contracting corps. The situation you describe is a special form of dilemma. A dilemma is a compound argument having two propositions (two lemmas) and a minor premise that is disjunctive, leading to a disjunctive conclusion. If A then B # first lemma If C then D # second lemma Either A or C # minor premise therefore Either B or D # conclusion If (good code) then (manager unhappy) If (bad code) then (manager happy) Either (manager happy) or (manager unhappy) therefore Either (food on the table) or (bad code) Some would mistakenly call this a Hobson's Choice. No, a Hobson's Choice offers a single choice, take it or leave it. The dilemma you present is commonly called extortion or blackmail, its technical name is Morton's Fork. "Elected officers (MPs and councillors) sometimes may have recourse to a variant on Morton's Fork when dealing with uncooperative non-elected officers (civil servants). This variant asserts that a non-elected officer's non-compliance with the directive of their elected officer must be due to one of two equally unacceptable causes: either the civil servant is lazy or incompetent, or the civil servant is acting willfully or maliciously against the instructions given by his/her elected officer." http://en.wikipedia.org/wiki/Morton%27s_Fork The fallacy, called false dichotomy, is that the minor premise is stated in consequents rather than antecedents. It is in the form: If A then B # first lemma If C then D # second lemma Either B or D # misstated minor premise therefore Either A or C # erroneous conclusion The true proposition "if A then B" does not imply the converse "if B then A". It could be that A and not E cause B. It could even be true that A and E cause D. Thus the dilemma could be rewritten If A and not E then B If C or (A and E) then D Either (A or C) and (E or not E) therefore: B or D The win-win solution is E, which puts food on the table (D) AND allows good code (A). A possible value of E is 'makes manager look good to his boss.'
From: Robert on 17 Jul 2008 01:21
On Wed, 16 Jul 2008 18:30:26 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote: >>>> On 7/15/2008 at 10:19 PM, in message ><pupq74t94srcr2ps97vc6qikc24he4gq1u(a)4ax.com>, Robert<no(a)e.mail> wrote: >> STRING 'SQL error in ' SQL-ERRLOC ' -- Consult documentation. ' >> DELMITED BY ' ' *> literal is 10 spaces >> INTO ERROR-MSG > >I guess I am one of those 'nervous programmers'. If only Cobol had >"DELIMITED BY TRAILING SPACES" or some such thing. Good point. The standards committee dropped the ball, then tried to recover by adding TRIM() to the 2008 spec. AcuCobol does have TRAILING SPACES. >> 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. > >How about trimming right spaces? MOVE ZEROS TO SQL-ERRLOC-LEN INSPECT ERRLOC TALLYING SQL-ERRLOC-LEN FOR CHARACTERS BEFORE INITIAL ' ' Not much better than ten spaces on STRING. >The best would be the proposed TRIM instrinsic function: >STRING 'SQL error in ' > FUNCTION TRIM(SQL-ERRLOC) > ' -- Consult documentation.' > DELIMITED BY SIZE > INTO ERROR-MSG > >OpenCobol supports it! But VSE won't in my lifetime. Ah well! Can't you write user-defined functions in VSE Cobol? |