variable length in REDEFINES
Frank Swarbrick
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
Arnold Trembley
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.
I tried this with Realia COBOL 1.0 from 1990, and it only gave a
warning message "Variable length OCCURS accepted in REDEFINES".
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?
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.
With kindest regards,
Vince Coen
12 Jul 08 01:36, Frank Swarbrick wrote to All:
FS> Can anyone give me a good reason why this copybook should give an
FS> error?
FS> 01 SQLLINK.
FS> 05 SQL-ERROR-INFO-IN PIC X(20).
FS> 05 REDEFINES SQL-ERROR-INFO-IN.
FS> 10 SQL-ERROR-ACTION PIC X.
Assuming the compiler puts in an implicit filler of x(19).
FS> 05 SQL-ERROR-INFO-OUT PIC X(20).
FS> 05 REDEFINES SQL-ERROR-INFO-OUT.
FS> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3.
Same as above.
FS> 05 ERRLOC PIC X(60).
FS> 05 SQL-ERRLOC REDEFINES ERRLOC.
FS> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN.
remove the '10' ie a redefines b pic x occurs 0 to 60 etc.
FS> Here's what I get:
FS> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS
FS> DEPENDING ON"
FS> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS
FS> DISCARDED.
FS> Now I'm not asking if it is in the standard or anything. I want to
FS> know *why*. It seems to me to be harmless, as long as the max
FS> occurance doesn't make the redefine exceed the length of the field it
FS> is redefining, and as long as there are no 05 levels following it.
FS> Not that it matters. If I can't do it then I can't do it. But it
FS> bugs me!
FS> :-)
FS> Frank
See what happens then.
Vince
Robert
wrote:
You don't need ERRLOC. Delete ERRLOC and the redefines clause.
William M. Klein
You didn't ask how to "fix" this code, but (as I understand it) WHY there was
such a restrction.
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).
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.
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.
***
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."
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:4877A825.6...@efirstbank.com...
Frank Swarbrick
<K6Zdk.222867$SV4....@bgtnsc04-news.ops.worldnet.att.net>, Arnold
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
Frank Swarbrick
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
Frank Swarbrick
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....@fe02.news.easynews.com>, William M.
Klein<wmk...@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
Pete Dashwood
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:487C7A1D.6...@efirstbank.com...
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."
Robert
wrote:
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.
Robert
>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:
docd...@panix.com
Robert <n...@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
Frank Swarbrick
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
Robert
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.'
Robert
wrote:
>>>> On 7/15/2008 at 10:19 PM, in message
><pupq74t94srcr2ps9...@4ax.com>, Robert<n...@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?
docd...@panix.com
To describe accurately, Mr Wagner, is not to denigrate. Are you syaing
your experience is so limited you've never met such a person?
>In the
>next sentence you
>say contracting is about doing the bidding of the one who signs your
>timecard, usually the
>same manager.
'He who pays the piper calls the tune' is a sentiment which pre-dates
computer programming by a few years, Mr Wagner. Are you saying your
experience is so limited you've never been exposed to it?
>Further, you imply that those who disagree should be
>stripped of their
>templates and drummed out of the contracting corps.
'Implication is in the mind of the beholder', Mr Wagner; try to address
what I wrote, not what you'd like to believe I have written. Have you
seen many pornographic inkblots recently?
>
>The situation you describe is a special form of dilemma.
What I've described, Mr Wagner, is in my experience nothing special at
all; it gives a rationale for a practise you disagree with that does not
involve incompetence on the part of coders or a slavish devotion to the
status quo ante, two horses I've seen flogged a few times in your postings
here... perhaps almost as often as others have seen Corner Office Idiots
described in my own postings, I've not counted.
DD
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>I guess I am one of those 'nervous programmers'. If only Cobol had
>"DELIMITED BY TRAILING SPACES" or some such thing.
I've found that I have moved away from one of the basics of CoBOL,
preferring to use reference modification to wordy commands. Do we
need DELIMITED BY TRAILING SPACES or TRIM to be clear? I think that
may be overkill, reference modification loops aren't hard to
understand.
Robert
There are several management types. The worst is a former programmer Peter Principled into
a corner office. For him, time stopped when he last wrote code. If he had trouble with,
say complex conditionals or the sort verb, those features will be verboten until he
retires. The shop will be stuck with old technology so long as he's there.
Managers like that are found in medium sized companies. They don't survive in large
companies like the ones where I perfer to work.
>>In the
>>next sentence you
>>say contracting is about doing the bidding of the one who signs your
>>timecard, usually the
>>same manager.
>
>'He who pays the piper calls the tune' is a sentiment which pre-dates
>computer programming by a few years, Mr Wagner. Are you saying your
>experience is so limited you've never been exposed to it?
I heard it often in Asian bars. Unlike IT contractors, whores set limits on how low
they'll go. They have more dignity.
>>Further, you imply that those who disagree should be
>>stripped of their
>>templates and drummed out of the contracting corps.
>
>'Implication is in the mind of the beholder', Mr Wagner; try to address
>what I wrote, not what you'd like to believe I have written. Have you
>seen many pornographic inkblots recently?
No, but just this morning I saw a repulsive GO TO DEPENDING ON. Fortunately, my stomach
was empty.
docd...@panix.com
The question posed to you, Mr Wagner, was not about management types or
where you prefer to work; you were asked if your experience encompassed
meeting a kind of person. You did not say that you had.
>
>>>In the next sentence you
>>>say contracting is about doing the bidding of the one who signs your
>>>timecard, usually the same manager.
>>
>>'He who pays the piper calls the tune' is a sentiment which pre-dates
>>computer programming by a few years, Mr Wagner. Are you saying your
>>experience is so limited you've never been exposed to it?
>
>I heard it often in Asian bars. Unlike IT contractors, whores set limits
>on how low
>they'll go. They have more dignity.
You were not asked about your what you frequently hear in Asian bars, Mr
Wagner, you were asked about your exposure to a sentiment. You did not
say you had been exposed to it.
>
>>>Further, you imply that those who disagree should be
>>>stripped of their
>>>templates and drummed out of the contracting corps.
>>
>>'Implication is in the mind of the beholder', Mr Wagner; try to address
>>what I wrote, not what you'd like to believe I have written. Have you
>>seen many pornographic inkblots recently?
>
>No, but just this morning I saw a repulsive GO TO DEPENDING ON.
With a little more experience and exposure, Mr Wagner, it might be that
you'll get to see one that is not repulsive. Until such time it might be
wise to insure that a better-experienced, better-exposed programmer is
available to deal with code.
DD
Frank Swarbrick
If you mean "FUNCTION-ID. TRIM." then no, you cannot. Cobol VSE supports
only the 1985 standard with the 1989 addenda, and nothing newer.
Frank
Frank Swarbrick
<dpku74pfes1grlmr4...@4ax.com>, Howard
No, but they are wordy, and I'd rather avoid them for something this basic.
Howard Brazee
>There are several management types. The worst is a former programmer Peter Principled into
>a corner office. For him, time stopped when he last wrote code. If he had trouble with,
>say complex conditionals or the sort verb, those features will be verboten until he
>retires. The shop will be stuck with old technology so long as he's there.
I've come across them - they are not the worst.
>Managers like that are found in medium sized companies. They don't survive in large
>companies like the ones where I perfer to work.
I've come across them in large companies. Sometimes we live with
their standards after they retire.
>>'He who pays the piper calls the tune' is a sentiment which pre-dates
>>computer programming by a few years, Mr Wagner. Are you saying your
>>experience is so limited you've never been exposed to it?
>
>I heard it often in Asian bars. Unlike IT contractors, whores set limits on how low
>they'll go. They have more dignity.
I've experienced both sides of IT contracting, and just as with
everything else I've experienced, how low we will go as whores is
variable.
I've read that it's variable with the kind of whores you mentioned as
well - but we are all whores, with different prices, and different
willingness to meet those prices.
>No, but just this morning I saw a repulsive GO TO DEPENDING ON. Fortunately, my stomach
>was empty.
I remember when that was taught and recommended. Old code doesn't
bother me anymore than old people. If it happened to be young code,
then my feeling is pity.
If I was the kind of person to get so easily repulsed, I couldn't go
to the bathroom, with results that are not favorable to my health and
happiness.
Howard Brazee
<Frank.S...@efirstbank.com> wrote:
>> I've found that I have moved away from one of the basics of CoBOL,
>> preferring to use reference modification to wordy commands. Do we
>> need DELIMITED BY TRAILING SPACES or TRIM to be clear? I think that
>> may be overkill, reference modification loops aren't hard to
>> understand.
>
>No, but they are wordy, and I'd rather avoid them for something this basic.
I have to try to decide which would be easier for maintenance
programmers to understand correctly. If the commands aren't used
much, I need to put in comments, but I've experienced maintenance
programmers updating the code, but not the comments.
Nowadays, I expect reference modification will be more obvious
(provided I code it with that in mind).
Pete Dashwood
"Howard Brazee" <how...@brazee.net> wrote in message
news:n33v74hs6ut0cusoh...@4ax.com...
> On Thu, 17 Jul 2008 12:39:43 -0500, Robert <n...@e.mail> wrote:
>
>
>>There are several management types. The worst is a former programmer Peter
>>Principled into
>>a corner office. For him, time stopped when he last wrote code. If he had
>>trouble with,
>>say complex conditionals or the sort verb, those features will be verboten
>>until he
>>retires. The shop will be stuck with old technology so long as he's there.
>
> I've come across them - they are not the worst.
>
>>Managers like that are found in medium sized companies. They don't survive
>>in large
>>companies like the ones where I perfer to work.
>
> I've come across them in large companies. Sometimes we live with
> their standards after they retire.
I've come across them in all sorts and sizes of companies. Large companies
have their share of managers who have reached their level of incompetence
(as Robert says, "Peter Principled"), and been sidelined into managing tech
teams. Fortunately, these are by no means the usual, and even some of them
actually learn how to manage and motivate "difficult" techies.
As a freelance PM I have been called upon a couple of times to manage tech
teams that no-one in the Organization would touch. "Difficult People"... I
found in both cases that the reason these guys were "difficult" was because
they had been constantly mismanaged over a number of years, until they had
developed nothing but scorn and disrespect for anyone in a management
capacity. It was further exacerbated by the fact that one of these teams was
comprised entirely of highly intelligent experts who tended to have little
time or patience for "normal" people anyway. :-)
While I am not stupid, most of the people on this team were smarter than I
am, and it was a very interesting exercise (and a growth experience for all
concerned, particularly self...) to get through to them and ensure that the
project goals were achieved. This was the only project I have ever managed
where I was sent to Coventry (for US readers that means "The Silent
Treatment"...) for around two weeks, the only project where I physically hit
someone (outside working hours but still not a recommended management
practice - I'm not proud of it...), and the only project where I have
started to seriously doubt whether I could make it happen. At the end of it,
(9 months down the track, with successful completion) the whole team
unanimously stated they weren't going anywhere unless I was the manager. It
was quite touching... :-) The point is that there are bad managers and there
are difficult teams, but differences can be resolved and respect can be
earned.
I believe that attitude has a lot to do with it. Unfortunately, this is an
intangible that is difficult to quantify and does not appear on the list of
requirements when recruiting. (It does on MY list... and it has a high
priority. If someone's attitude is right they can be helped and assisted to
attain the skills they may not have in spades. Furthermore, it is an asset
to any team (manager and staff) to work with people who actually enjoy
coming to work in the morning.)
>
>
>>>'He who pays the piper calls the tune' is a sentiment which pre-dates
>>>computer programming by a few years, Mr Wagner. Are you saying your
>>>experience is so limited you've never been exposed to it?
>>
>>I heard it often in Asian bars. Unlike IT contractors, whores set limits
>>on how low
>>they'll go. They have more dignity.
I have sometimes shocked colleagues by pointing out that freelancers like
myself are really just "cyberwhores". I'll take on any project (well,
almost... there have been one or two which I declined on ethical grounds
even though the money was obscene...and just as well, as it transpired
later...), if the price is right. I don't disrespect whores (or anyone else)
based on the work they do, so I have no problem being categorized as one.
In response to Robert, I have to say that (just like his Asian whore) I also
set a limit on how low I will go. Not sure if that gives me more dignity or
not... :-) Fortunately, the market for my services has been bouyant enough
over the last forty years that my lower limit has never been put to the
test.
>
> I've experienced both sides of IT contracting, and just as with
> everything else I've experienced, how low we will go as whores is
> variable.
>
> I've read that it's variable with the kind of whores you mentioned as
> well - but we are all whores, with different prices, and different
> willingness to meet those prices.
Absolutely. It is just pretentious to be offended by the idea.
>
>
>>No, but just this morning I saw a repulsive GO TO DEPENDING ON.
>>Fortunately, my stomach
>>was empty.
>
> I remember when that was taught and recommended.
Yeah, me too... :-) In fact, in IMS DC and to a lesser extent even with
CICS, where serially reusability was required, GO TO... DEPENDING was the
accepted and endorsed way of implementing re-entrance across dequeue
boundaries...
> Old code doesn't
> bother me anymore than old people. If it happened to be young code,
> then my feeling is pity.
Nicely expressed, Howard. I agree.
>
> If I was the kind of person to get so easily repulsed, I couldn't go
> to the bathroom, with results that are not favorable to my health and
> happiness.
No comment... :-)
Pete Dashwood
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:487F372A.6...@efirstbank.com...
Fujitsu extends COBOL with the following intrinsic function:
STORED-CHAR-LENGTH Function
This function returns the length of the effective characters (without
training blanks)
contained in argument-1.
The STORED-CHAR-LENGTH function is specific to Win32, Sun and Linux.
For details about how to use the examples, refer to "STORED-CHAR-LENG
Function"
in the "Syntax Samples".
Format
FUNCTION STORED-CHAR-LENGTH (argument-1)
Argument
1. Argument-1 must be alphanumeric or national characters. It must not be a
group item. (It can be 01 with a picture... Pete)
2. Argument-1 must consist of one or more characters.
Function Value
1. The function value is the number of character positions of the effective
characters contained in argument-1.
2. When argument-1 is the alphanumeric class, the function value indicates
the
number of alphanumeric character positions of the effective characters.
3. When argument-1 is the national class, the function value indicates the
number
of national character positions of the effective characters.
4. The characters stored in argument-1 must follow the encoding forms
dictated by
the class of argument-1. Otherwise, the result is undefined.
Function Type
The function type is integer.
Although it isn't clear above, I have found from extensive use of this
function (it is very useful...) that the number it returns is the ordinal
position of the last non-blank character in the string, so embedded spaces
(any number) are fine and get counted.
I'm inclined to agree with Robert that it must be possible to write such a
function easily in COBOL and put it in the same library as the other
intrinsic functions that ARE available with VSE. Try having a chat to your
friendly neighbourhood systems programmer... if the guy is good he might be
very happy to to indulge you. I'd be surprised if IBM don't allow
maintenance of these libraries. (You're not changing any existing
functionality, just extending it....now, where have we heard that before...?
Oh yeah, standard practice with OO...:-)
Here's another idea :-) Why not write your function/module/whatever then
replace one of the unused intrinsics with it (say COS...) if there really is
no way to add to the compiler's function library... (no, Frank, I was
joking...:-))
Roger While
"Pete Dashwood" <dash...@removethis.enternet.co.nz> schrieb im Newsbeitrag
news:6eahskF...@mid.individual.net...
> Fujitsu extends COBOL with the following intrinsic function:
>
> STORED-CHAR-LENGTH Function
>
> This function returns the length of the effective characters (without
> training blanks)
> contained in argument-1.
> The STORED-CHAR-LENGTH function is specific to Win32, Sun and Linux.
> For details about how to use the examples, refer to "STORED-CHAR-LENG
> Function"
> in the "Syntax Samples".
OpenCOBOL also has this function.
Roger
Pete Dashwood
"Roger While" <si...@sim-basis.de> wrote in message
news:g5q2vs$8ov$02$1...@news.t-online.com...
Excellent! Good job, Roger.
Is OC going to be the first implementation of the 2002 standard?
When is it likely to be RTM?
Howard Brazee
<dash...@removethis.enternet.co.nz> wrote:
>I have sometimes shocked colleagues by pointing out that freelancers like
>myself are really just "cyberwhores". I'll take on any project (well,
>almost... there have been one or two which I declined on ethical grounds
>even though the money was obscene...and just as well, as it transpired
>later...), if the price is right. I don't disrespect whores (or anyone else)
>based on the work they do, so I have no problem being categorized as one.
Often, when either type of whore has too low standards, the
consequences bite us later.
William M. Klein
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:6eahskF...@mid.individual.net...
<snip>
> I'm inclined to agree with Robert that it must be possible to write such a
> function easily in COBOL and put it in the same library as the other intrinsic
> functions that ARE available with VSE. Try having a chat to your friendly
> neighbourhood systems programmer... if the guy is good he might be very happy
> to to indulge you. I'd be surprised if IBM don't allow maintenance of these
> libraries. (You're not changing any existing functionality, just extending
> it....now, where have we heard that before...? Oh yeah, standard practice with
> OO...:-)
>
functions. Some (but not any IBM mainframe one) do allow for user-defined
funcitons, but they have syntaxtic differences from intrinsic functions (just a
the '02 Standard would expect).
Actually, I think that IBM mainframe programmers COULD (if they really wanted
to) create pseduo-intrinsic functions. If you created an "EXIT" - see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYVA002/APPENDIX1.4
routine, you could create a CALLed subroutine that returned a "trimmed" value in
the RETURNED field.
However, that would be SO much work (for such little return), I find it pretty
hard to believe that anyone would do it.
Pete Dashwood
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:ci8gk.255768$Ev5.1...@fe09.news.easynews.com...
>
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
> news:6eahskF...@mid.individual.net...
> <snip>
>> I'm inclined to agree with Robert that it must be possible to write such
>> a function easily in COBOL and put it in the same library as the other
>> intrinsic functions that ARE available with VSE. Try having a chat to
>> your friendly neighbourhood systems programmer... if the guy is good he
>> might be very happy to to indulge you. I'd be surprised if IBM don't
>> allow maintenance of these libraries. (You're not changing any existing
>> functionality, just extending it....now, where have we heard that
>> before...? Oh yeah, standard practice with OO...:-)
>>
> I don't know of ANY compiler that allows one to add "user-defined'
> INTRINISC functions. Some (but not any IBM mainframe one) do allow for
> user-defined funcitons, but they have syntaxtic differences from intrinsic
> functions (just a the '02 Standard would expect).
My comments were based on the hypothetical assumption that it was absolutely
necessary to do it, not the real world practicalities where it simply isn't.
:-)
It is sometimes surprising the things that sysprogs will do if they are
bored... :-)
>
> Actually, I think that IBM mainframe programmers COULD (if they really
> wanted to) create pseduo-intrinsic functions. If you created an "EXIT" -
> see:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYVA002/APPENDIX1.4
>
> routine, you could create a CALLed subroutine that returned a "trimmed"
> value in the RETURNED field.
>
> However, that would be SO much work (for such little return), I find it
> pretty hard to believe that anyone would do it.
Fair comment, Bill.
There are problems with using CALL as opposed to an intrinsic because it is
less flexible, and has to be resolved before it can be used in an
expression.
However, suppose, just as an academic exercise, you HAD to do it? (My
comments were based on that assumption)
The fact is that the compiler uses a library of intrinsic functions, and
connects them into object code by SOME mechanism. (We could speculate
whether it is inline or based on weak EXTERNs... doesn't really matter. Some
investigation would determine how it worked. Once the way it works is
determined, it shouldn't be hard to add another function to it... :-)
Having patched compilers in the past to do things they were never designed
to do, I would find this an interesting exercise. You might think of it as
just another (albeit, "unoffical") PTF... :-) If I were Frank, I'd certainly
talk to the local sysprog. Over a cup of coffee it might become a useful
site function.
OR, I guess one COULD go to SHARE and suggest it be included by IBM, then
wait indefinitely for it... :-)
P.S. I am not entirely serious about this...
Frank Swarbrick
<6eahskF...@mid.individual.net>,
I've seen no indication that this is possible, and even if it were I doubt
my system programmers would touch it with a 100 foot pole. Though if it
were possible I'd try to give it a shot. But it's very unlikely.
>
> Here's another idea :-) Why not write your function/module/whatever then
> replace one of the unused intrinsics with it (say COS...) if there
> really is
> no way to add to the compiler's function library... (no, Frank, I was
> joking...:-))
No idea how to do this either, but I'm sure something so unsupported would
never be allowed in production.
Frank
Pete Dashwood
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:4881CA85.6...@efirstbank.com...
I'm sure you're right...
These days with "best practices" and SOPs and standards and dire warnings
from vendors if you mess with their products, there isn't much fun any
more...:-)
I remember a time when we were constrained by none of this and just did what
was necessary... :-)
When I look back over some of the things I've been required to do in my
career, it makes me smile. Here are some examples which I couldn't see
being even entertained today....
1. Patch a COBOL compiler so it can read magnetic tape or disk input instead
of just punch cards.
2. Write a facility to save object programs from a fixed disk, where the
compiler put them, into a library on tape, that could be reloaded and
reused, so that compilation wasn't necessary every time you needed to run an
application.
3. Find which pass of the COBOL compiler deals with generation for IF
statements and fix it so that else branch code is only generated when it
actually needs to be, instead of "always"...
4. Write a common interface that traps DL/1 calls and re-interprets them to
SQL so that all our DL/1 programs can be switched to DB2.
5. Write a common interface that traps TASKMASTER calls and converts them
to IMS/DC.
6. Write an application that allows users to specify their own search
criteria and generate a program to do it. (This was before SQL was
invented).
7. Devise a common data access layer that would allow COBOL to run across
different platforms (IBM and ICL... but theoretically ANY) so that the same
processing can occur against completely different data management systems.
8. Write something that will allow Fujitsu mainframe applications to run on
a PC, with the same look and feel. (This was a tragedy for me... I did it,
got it working, demonstrated it to Fujitsu (Australia) and had a handshake
on a deal that would have had me retired at 42 years of age (multimillion
dollar deal). The day before the contract was to be signed the whole deal
with their customer collapsed and they couldn't proceed. :-). I shrugged,
paid my associates and walked away, but my wife was devasted... she was
already buying shoes :-)
There are more, but you catch my drift... :-)
Adding a new intrinsic function to an IBM COBOL compiler really isn't such a
big deal... :-)