Home > Archive > Cobol > June 2007 > Setting A Hex Value in COBOL
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Setting A Hex Value in COBOL
|
|
|
| I have to modify an old COBOL program which probably hasn't been touched
since the mid-90's. And it's probably been almost as long since I've
touched COBOL. Part of what happens in the program is the setting of some
printer control codes which are sent to some downstream printers in CICS.
The following snippet of code shows how some of the control codes are
currently being set. It seems pretty straightforward. For instance, the
redefinition of CH-FF-BIN with its value of +12 causes the CH-FF field to
contain X'0C. Simarly, CH-1D-BIN with its value of +29 causes the CH-1D
filed to contain a X'1D'.
01 CH-NL-BIN PIC S9(4) COMP VALUE +21.
01 FILLER REDEFINES CH-NL-BIN.
02 FILLER PIC X.
02 CH-NL PIC X.
01 CH-FF-BIN PIC S9(4) COMP VALUE +12.
01 FILLER REDEFINES CH-FF-BIN.
02 FILLER PIC X.
02 CH-FF PIC X.
01 CH-1D-BIN PIC S9(4) COMP VALUE +29.
01 FILLER REDEFINES CH-1D-BIN.
02 FILLER PIC X.
02 CH-1D PIC X.
01 CH-56-BIN PIC S9(4) COMP VALUE +86.
01 FILLER REDEFINES CH-56-BIN.
02 FILLER PIC X.
02 CH-56 PIC X.
01 CH-31-BIN PIC S9(4) COMP VALUE +49.
01 FILLER REDEFINES CH-31-BIN.
02 FILLER PIC X.
02 CH-31 PIC X.
My question is this. I need to add a field which would end up containing a
X'E5'. The decimal equivalent is +229. Since the value of the field is
3-digits, will it still "fit" into the PIC X field? Would it look something
like this?
01 CH-E5-BIN PIC S9(4) COMP VALUE +229.
01 FILLER REDEFINES CH-E5-BIN.
02 FILLER PIC X.
02 CH-E5 PIC X.
This is some old MVS COBOL II code. Is there actually a better way to be
performing this function? Is there anything like MOVE X'E5' to CH-E5?
Thank you.
Gary
| |
|
| In article <%yj7i.172509$nh4.82579@newsfe20.lga>,
gary <garyinri@yahoo.com> wrote:
>I have to modify an old COBOL program which probably hasn't been touched
>since the mid-90's.
Oh, come now... it probably saw some Y2K remediation, check the date on
the load module in Prod.
[snip]
> 01 CH-NL-BIN PIC S9(4) COMP VALUE +21.
> 01 FILLER REDEFINES CH-NL-BIN.
> 02 FILLER PIC X.
> 02 CH-NL PIC X.
> 01 CH-FF-BIN PIC S9(4) COMP VALUE +12.
> 01 FILLER REDEFINES CH-FF-BIN.
> 02 FILLER PIC X.
> 02 CH-FF PIC X.
> 01 CH-1D-BIN PIC S9(4) COMP VALUE +29.
> 01 FILLER REDEFINES CH-1D-BIN.
> 02 FILLER PIC X.
> 02 CH-1D PIC X.
> 01 CH-56-BIN PIC S9(4) COMP VALUE +86.
> 01 FILLER REDEFINES CH-56-BIN.
> 02 FILLER PIC X.
> 02 CH-56 PIC X.
> 01 CH-31-BIN PIC S9(4) COMP VALUE +49.
> 01 FILLER REDEFINES CH-31-BIN.
> 02 FILLER PIC X.
> 02 CH-31 PIC X.
Hmmmmm... smells older than the 1990s. My guess is that NL is a NewLine
and FF is a FormFeed.
>
>My question is this. I need to add a field which would end up containing a
>X'E5'. The decimal equivalent is +229. Since the value of the field is
>3-digits, will it still "fit" into the PIC X field?
Wait, now I'm  ... X'E5' is not '3-digits', it is a single byte.
>Would it look something
>like this?
>
> 01 CH-E5-BIN PIC S9(4) COMP VALUE +229.
> 01 FILLER REDEFINES CH-E5-BIN.
> 02 FILLER PIC X.
> 02 CH-E5 PIC X.
I'm assuming that this new E5 code is supposed to... *do* something, in a
manner similar to the other codes. This indicates that there's at least
two ways to test it, either by debugging or just sending off a 'let's go
see!' run.
>
>This is some old MVS COBOL II code. Is there actually a better way to be
>performing this function? Is there anything like MOVE X'E5' to CH-E5?
That's supported in some dialects of COBOL, aye. Is there something that
prevents you from seeing what kind of compile errors it might throw?
DD
| |
|
| DD,
Program was last modified on 6-8-1994 and probably was originally developed
in the 80's. No date handling in the code so no Y2K remediation was needed.
Yes, the FF an NL do represent the codes for a NewLine and a FormFeed. As
for the "3-digits", I was referring to the 229, not the E5.
The reason I was trying to gather a little info first was that we have to
submit requests to our DBA group to get something complied and copied.
There are times that things don't get turned around too quickly, so I'm
trying to minimize the number of requests I need to make. But yes, at this
point, I plan on just throwing the code out there and testing it with a
"let's go see" run.
Gary
<docdwarf@panix.com> wrote in message news:f3kho1$63n$1@reader2.panix.com...
> In article <%yj7i.172509$nh4.82579@newsfe20.lga>,
> gary <garyinri@yahoo.com> wrote:
>
> Oh, come now... it probably saw some Y2K remediation, check the date on
> the load module in Prod.
>
> [snip]
>
>
> Hmmmmm... smells older than the 1990s. My guess is that NL is a NewLine
> and FF is a FormFeed.
>
a[color=darkred]
>
> Wait, now I'm ... X'E5' is not '3-digits', it is a single byte.
>
>
> I'm assuming that this new E5 code is supposed to... *do* something, in a
> manner similar to the other codes. This indicates that there's at least
> two ways to test it, either by debugging or just sending off a 'let's go
> see!' run.
>
>
> That's supported in some dialects of COBOL, aye. Is there something that
> prevents you from seeing what kind of compile errors it might throw?
>
> DD
>
| |
| William M. Klein 2007-05-30, 6:55 pm |
| The bottom-line answer to your original question is that
Yes, the VS COBOL II compiler (what I think you mean by "MVS COBOL II) compiler
supports hex-literals.
HOWEVER, only if you are using the NOCMPR2 compiler option. It looks like you
have an "old" OS/VS COBOL program that may have been recompiled with VS COBOL
II. You will need to check what compiler options were used (in 1994) and which
version of the compiler was used.
FYI,
The information is online. For example, check out:
http://publibz.boulder.ibm.com/cgi-...yl1101/1.1.1.11
--
Bill Klein
wmklein <at> ix.netcom.com
"gary" <garyinri@yahoo.com> wrote in message
news:0sk7i.362283$2Q1.84574@newsfe16.lga...
> DD,
>
> Program was last modified on 6-8-1994 and probably was originally developed
> in the 80's. No date handling in the code so no Y2K remediation was needed.
> Yes, the FF an NL do represent the codes for a NewLine and a FormFeed. As
> for the "3-digits", I was referring to the 229, not the E5.
>
> The reason I was trying to gather a little info first was that we have to
> submit requests to our DBA group to get something complied and copied.
> There are times that things don't get turned around too quickly, so I'm
> trying to minimize the number of requests I need to make. But yes, at this
> point, I plan on just throwing the code out there and testing it with a
> "let's go see" run.
>
> Gary
>
>
> <docdwarf@panix.com> wrote in message news:f3kho1$63n$1@reader2.panix.com...
> a
>
>
| |
|
| William M. Klein wrote:
> The bottom-line answer to your original question is that
>
> Yes, the VS COBOL II compiler (what I think you mean by "MVS COBOL II) compiler
> supports hex-literals.
>
> HOWEVER, only if you are using the NOCMPR2 compiler option. It looks like you
> have an "old" OS/VS COBOL program that may have been recompiled with VS COBOL
> II. You will need to check what compiler options were used (in 1994) and which
> version of the compiler was used.
>
> FYI,
> The information is online. For example, check out:
> http://publibz.boulder.ibm.com/cgi-...yl1101/1.1.1.11
The real question in this case is not what compiler was used to compile
it in 1994 [although that could imply some other changes to the source],
but what compiler do you have now that will be used to compile the
changed program? And, please be very specific and accurate about the
name, version/release of the compiler. Bill's referenced document is
the COBOL II manual.
Carl
| |
|
| In article <0sk7i.362283$2Q1.84574@newsfe16.lga>,
gary <garyinri@yahoo.com> wrote:
>DD,
>
>Program was last modified on 6-8-1994 and probably was originally developed
>in the 80's. No date handling in the code so no Y2K remediation was needed.
Wow... and they still managed to find the source code? Good for them,
I've worked in far too many places where stuff gets moved around and the
system becomes closer than it should be to OCO.
>Yes, the FF an NL do represent the codes for a NewLine and a FormFeed. As
>for the "3-digits", I was referring to the 229, not the E5.
Well... win some, lose some. It might be interesting to find out what the
various codes do, just for laffs.
>
>The reason I was trying to gather a little info first was that we have to
>submit requests to our DBA group to get something complied and copied.
Now I'm lost again. I'm familiar with the necessity for (group) to have
responsibility for moving something from Development to Test to Prod, and
Great Magicks blessed by many of the High Ones needed to do so... but are
you saying that when you need any sort of compile the DBA has to do it?
>There are times that things don't get turned around too quickly, so I'm
>trying to minimize the number of requests I need to make.
This sounds like something back from Ye Oldene Dayse... a programmer is
allowed two (or more or less) compiles per day because those CPU cycles
cost big money and all that. What I'm hearing here is that you get some
code, put your mods in, submit a request to the DBA to compile, get a 12
back because you fat-fingered CH-NL into CH0NL, change the '0' to a '-',
submit a request to a DBA to compile, get a 12 back because you typo'd
PERFORM into PERFROM, change the code, submit a request...
I wonder what Productivity Improvement Structures and Steps will be
introduced next... maybe they'll have you work on coding sheets,
desk-check things to death and submit your pads to the card-punch girls to
be keyed in.
>But yes, at this
>point, I plan on just throwing the code out there and testing it with a
>"let's go see" run.
That's the spirit... if things are as bad as I described above I'd be
happy to email you generic compile-JCL, invoking IGYCRCTL and HEWL... all
you'd have to do is find out what libraries they have hidden such
treasures in... and hope that you're not RACF'd out.
DD
| |
|
| In article <3c83c$465e0b40$d06620ed$12387@FUSE.NET>,
CG <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote:
[snip]
>The real question in this case is not what compiler was used to compile
>it in 1994 [although that could imply some other changes to the source],
>but what compiler do you have now that will be used to compile the
>changed program?
It seems, Mr Gehr, that such information might - in a shop where compiles
have to be done by DBAs - be considered Top Secret.
DD
| |
| Pete Dashwood 2007-05-30, 9:55 pm |
|
"gary" <garyinri@yahoo.com> wrote in message
news:%yj7i.172509$nh4.82579@newsfe20.lga...
>I have to modify an old COBOL program which probably hasn't been touched
> since the mid-90's. And it's probably been almost as long since I've
> touched COBOL. Part of what happens in the program is the setting of some
> printer control codes which are sent to some downstream printers in CICS.
>
> The following snippet of code shows how some of the control codes are
> currently being set. It seems pretty straightforward. For instance, the
> redefinition of CH-FF-BIN with its value of +12 causes the CH-FF field to
> contain X'0C. Simarly, CH-1D-BIN with its value of +29 causes the CH-1D
> filed to contain a X'1D'.
>
>
> 01 CH-NL-BIN PIC S9(4) COMP VALUE +21.
> 01 FILLER REDEFINES CH-NL-BIN.
> 02 FILLER PIC X.
> 02 CH-NL PIC X.
> 01 CH-FF-BIN PIC S9(4) COMP VALUE +12.
> 01 FILLER REDEFINES CH-FF-BIN.
> 02 FILLER PIC X.
> 02 CH-FF PIC X.
> 01 CH-1D-BIN PIC S9(4) COMP VALUE +29.
> 01 FILLER REDEFINES CH-1D-BIN.
> 02 FILLER PIC X.
> 02 CH-1D PIC X.
> 01 CH-56-BIN PIC S9(4) COMP VALUE +86.
> 01 FILLER REDEFINES CH-56-BIN.
> 02 FILLER PIC X.
> 02 CH-56 PIC X.
> 01 CH-31-BIN PIC S9(4) COMP VALUE +49.
> 01 FILLER REDEFINES CH-31-BIN.
> 02 FILLER PIC X.
> 02 CH-31 PIC X.
>
> My question is this. I need to add a field which would end up containing
> a
> X'E5'. The decimal equivalent is +229. Since the value of the field is
> 3-digits, will it still "fit" into the PIC X field? Would it look
> something
> like this?
>
> 01 CH-E5-BIN PIC S9(4) COMP VALUE +229.
> 01 FILLER REDEFINES CH-E5-BIN.
> 02 FILLER PIC X.
> 02 CH-E5 PIC X.
Yes, that will work fine. You will have hex '00E5' in CH-E5-BIN, x'E5' in
CH-E5...
Remember that CH-E5-BIN is a binary halfword (two bytes). Therefore,
although the value is 'three digits' it can be accommodated into a single
byte. In fact, any value up to 255 would be OK... (It is only 'three digits'
because you are thinking in decimal :-))
>
> This is some old MVS COBOL II code. Is there actually a better way to be
> performing this function? Is there anything like MOVE X'E5' to CH-E5?
I believe I have used exactly this in VS COBOL II for IBM mainframes. It
might depend on what compiler options were in force and, as I worked on many
different sites I can't be sure. Worth a try though.
Pete.
| |
|
| docdwarf@panix.com wrote:
> In article <3c83c$465e0b40$d06620ed$12387@FUSE.NET>,
> CG <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote:
>
> [snip]
>
>
> It seems, Mr Gehr, that such information might - in a shop where compiles
> have to be done by DBAs - be considered Top Secret.
Do they also not allow programmers to look at the compile listing for
their programs? The first line of recent compiler listings will have
something like:
> PP 5655-G53 IBM Enterprise COBOL for z/OS 3.3.1
But, actually, my experience is that in a large number of shops, DBAs
know less about the compiler in use than do the programmers. The
programmers may not have control over the compiler, and they may not
know the differences across versions/releases. But they are usually
quite aware of what compiler they are using. Of course, they may use
the wrong name for the compiler [e.g., It is COBOL II, not COBOL2; and
COBOL3 is totally meaningless, other than it probably refers to one of
three versions and numerous releases of an LE-Conforming compiler.]
So, I'd like to hear the answer from Gary. I'll bet he either knows, or
can easily find out...
Carl
| |
| William M. Klein 2007-05-31, 3:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5c6j97F2ve8jcU1@mid.individual.net...
<snip>
> Remember that CH-E5-BIN is a binary halfword (two bytes). Therefore, although
> the value is 'three digits' it can be accommodated into a single byte. In
> fact, any value up to 255 would be OK... (It is only 'three digits' because
> you are thinking in decimal :-))
>
What Pette says above is true AND FALSE. As the OP mentioned an IBM mainframe
compiler, this will totally depend upon what setting of TRUNC is specified - and
how the field is used. If one wants to be "totally safe" it is NEVER a "good
idea" to put a 3 (decimal) digit value into a field defined with "PIC 9(2)" -
regardless of USAGE (unless using an implementer defined usage that SAYS this is
OK, such as COMP-5 or COMP-X in some compilers).
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Rick Smith 2007-05-31, 3:55 am |
|
"gary" <garyinri@yahoo.com> wrote in message
news:%yj7i.172509$nh4.82579@newsfe20.lga...
> I have to modify an old COBOL program which probably hasn't been touched
> since the mid-90's. And it's probably been almost as long since I've
> touched COBOL. Part of what happens in the program is the setting of some
> printer control codes which are sent to some downstream printers in CICS.
>
> The following snippet of code shows how some of the control codes are
> currently being set. It seems pretty straightforward. For instance, the
> redefinition of CH-FF-BIN with its value of +12 causes the CH-FF field to
> contain X'0C. Simarly, CH-1D-BIN with its value of +29 causes the CH-1D
> filed to contain a X'1D'.
>
>
> 01 CH-NL-BIN PIC S9(4) COMP VALUE +21.
> 01 FILLER REDEFINES CH-NL-BIN.
> 02 FILLER PIC X.
> 02 CH-NL PIC X.
> 01 CH-FF-BIN PIC S9(4) COMP VALUE +12.
> 01 FILLER REDEFINES CH-FF-BIN.
> 02 FILLER PIC X.
> 02 CH-FF PIC X.
> 01 CH-1D-BIN PIC S9(4) COMP VALUE +29.
> 01 FILLER REDEFINES CH-1D-BIN.
> 02 FILLER PIC X.
> 02 CH-1D PIC X.
> 01 CH-56-BIN PIC S9(4) COMP VALUE +86.
> 01 FILLER REDEFINES CH-56-BIN.
> 02 FILLER PIC X.
> 02 CH-56 PIC X.
> 01 CH-31-BIN PIC S9(4) COMP VALUE +49.
> 01 FILLER REDEFINES CH-31-BIN.
> 02 FILLER PIC X.
> 02 CH-31 PIC X.
>
> My question is this. I need to add a field which would end up containing
a
> X'E5'. The decimal equivalent is +229. Since the value of the field is
> 3-digits, will it still "fit" into the PIC X field? Would it look
something
> like this?
>
> 01 CH-E5-BIN PIC S9(4) COMP VALUE +229.
> 01 FILLER REDEFINES CH-E5-BIN.
> 02 FILLER PIC X.
> 02 CH-E5 PIC X.
>
> This is some old MVS COBOL II code. Is there actually a better way to be
> performing this function? Is there anything like MOVE X'E5' to CH-E5?
Whether anything is better may be entirely subjective;
but two other methods come to mind, both of which
seem to have become available with VS COBOL II.
1. Symbolic characters (ANSI 85):
[Note that values given here are 1 greater than the
actual character.]
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
SYMBOLIC CHARACTERS
CH-NL IS 22
CH-FF IS 13
CH-1D IS 30
CH-56 IS 87
CH-31 IS 50
CH-E5 IS 230.
2. Hexadecimal literals (VS COBOL II extension):
DATA DIVISION.
WORKING-STORAGE SECTION.
01 FILLER.
02 CH-NL PIC X VALUE X"15".
02 CH-FF PIC X VALUE X"0C".
02 CH-1D PIC X VALUE X"1D".
02 CH-56 PIC X VALUE X"56".
02 CH-31 PIC X VALUE X"31".
02 CH-E5 PIC X VALUE X"E5".
The use of symbolic characters may generate MVI
instructions and not require any working-storage.
This use of hexadecimal literals in working-storage
may generate MVC instructions; but use less
working-storage than the existing method. Extending
the existing method may be more consistent with
other programs in the system. These are the choices
I see.
| |
|
| In article <2Fs7i.159356$oS7.144347@fe04.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
[snip]
>If one wants to be "totally safe" it is NEVER a "good
>idea" to put a 3 (decimal) digit value into a field defined with "PIC 9(2)" -
>regardless of USAGE (unless using an implementer defined usage that SAYS
>this is
>OK, such as COMP-5 or COMP-X in some compilers).
I believe that the original poster specified that the target of the +229
VALUE clause was an S9(4) COMP field which had been REDEFINED into two PIC
X fields.
DD
| |
|
| In article <135sn0achcmu88@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
>"gary" <garyinri@yahoo.com> wrote in message
>news:%yj7i.172509$nh4.82579@newsfe20.lga...
[snip]
>a
>
>Whether anything is better may be entirely subjective;
>but two other methods come to mind, both of which
>seem to have become available with VS COBOL II.
>
>1. Symbolic characters (ANSI 85):
>[Note that values given here are 1 greater than the
>actual character.]
>
> ENVIRONMENT DIVISION.
> CONFIGURATION SECTION.
> SPECIAL-NAMES.
> SYMBOLIC CHARACTERS
> CH-NL IS 22
> CH-FF IS 13
> CH-1D IS 30
> CH-56 IS 87
> CH-31 IS 50
> CH-E5 IS 230.
>
>2. Hexadecimal literals (VS COBOL II extension):
>
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 FILLER.
> 02 CH-NL PIC X VALUE X"15".
> 02 CH-FF PIC X VALUE X"0C".
> 02 CH-1D PIC X VALUE X"1D".
> 02 CH-56 PIC X VALUE X"56".
> 02 CH-31 PIC X VALUE X"31".
> 02 CH-E5 PIC X VALUE X"E5".
>
>The use of symbolic characters may generate MVI
>instructions and not require any working-storage.
>This use of hexadecimal literals in working-storage
>may generate MVC instructions; but use less
>working-storage than the existing method. Extending
>the existing method may be more consistent with
>other programs in the system. These are the choices
>I see.
Hmmmmm... the program, Mr Plinston, uses a method I was taught lo, those
many years ago, of REDEFINING a two-byte COMP field so that the
lower-order byte contained the hexval that was needed; COBOLII-like
features have obviated the need for this bit of skill. (Being able to
address X'nn' directly and as such was one of the more delightful things I
found in my first copy of MicroFocus... 1.8, I think, I still have a copy,
somewhere, that runs off of three 720K floppies.)
Anyhow... I'd favor your second suggestion over your first; the 'you have
to remember to subtract 1' is something I've seen bite folks unfamiliar
with the intricacies of such things while 'VALUE IS X'0F'' is, to my eye,
a bit harder to misinterpret.
As for the code generated by either... I'd say they'd both be made into
MVIs; even IKFCBL00 was capable of differentiating single- and multi-byte
fields and taking that particular bit of advantage... but I may have some
spare time today and fun a few compiles... I work in a Most Advanced Shop,
you see, and even though I introduced the first VSAM KSDS with an
alternate index into our little chunk of Production in 2004 I'm not only
allowed to submit compiles without the DBA's approval... after a bit of
hunting I was able to make my own compile streams for both OldBOL and
NewBOL.
DD
| |
|
| In article <85fc9$465e3e7f$d06620ed$27450@FUSE.NET>,
CG <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote:
>docdwarf@panix.com wrote:
>
>Do they also not allow programmers to look at the compile listing for
>their programs?
I barely know what *I* allow, Mr Gehr, let alone anyone else.
DD
| |
| Pete Dashwood 2007-05-31, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:2Fs7i.159356$oS7.144347@fe04.news.easynews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5c6j97F2ve8jcU1@mid.individual.net...
> <snip>
> What Pette says above is true AND FALSE. As the OP mentioned an IBM
> mainframe compiler, this will totally depend upon what setting of TRUNC is
> specified - and how the field is used. If one wants to be "totally safe"
> it is NEVER a "good idea" to put a 3 (decimal) digit value into a field
> defined with "PIC 9(2)" - regardless of USAGE (unless using an implementer
> defined usage that SAYS this is OK, such as COMP-5 or COMP-X in some
> compilers).
>
I was aware of the TRUNC NOTRUNC options but I believe that neither of them
will affect this - correct me if I'm wrong. The field is defined as 4 digits
and is binary, a value no greater than 255 is being placed in it. Truncation
to 4 digits or non-truncation of 5 digits will have no effect on this
particular case, as far as I can see. I have used exactly this approach on a
number of installations and never had a problem with it. (Maybe they all had
the same defaults).
There is no question of a PIC 9(2) field being involved... It is a halfword
redefined to PIC XX.
I posted because the OP was getting a lot of whys and wherefores when really
all that was needed was a simple "yes" or "no".
Pete.
| |
|
| In article <5c84r7F2vuab1U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
[snip]
>I posted because the OP was getting a lot of whys and wherefores when really
>all that was needed was a simple "yes" or "no".
How nice to learn that there are folks to whom what is 'really all that
was needed was...' is so readily apparent... but, to others, it may sound
like it goes nigh hand-in-hand with the 'all ya gotta do is...' syndrome.
DD
| |
| Pete Dashwood 2007-05-31, 6:55 pm |
|
<docdwarf@panix.com> wrote in message news:f3mn1r$geg$1@reader2.panix.com...
> In article <5c84r7F2vuab1U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>
> How nice to learn that there are folks to whom what is 'really all that
> was needed was...' is so readily apparent... but, to others, it may sound
> like it goes nigh hand-in-hand with the 'all ya gotta do is...' syndrome.
>
> DD
>
You are the onl;y person I know who seems bothered by "all ya gotta do..."
Oversimplification can certainly be tedious, but each case should be judged
on its merits. There are times when "all ya gotta do" IS all you have to do.
As I don't share your aversion to this phrase, for the reasons outlined
above, whether or not some other statement I made seems close to it, is of
no consequence to me whatsoever.
Pete.
| |
|
| In article <5c86etF2v8e0iU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f3mn1r$geg$1@reader2.panix.com...
>
>You are the onl;y person I know who seems bothered by "all ya gotta do..."
I seem to recall a few folks here who share my initial distrust of a
Manager prefacing a solution with 'All ya gotta do is...' ... but I'm sure
they can speak for themselves.
>
>Oversimplification can certainly be tedious, but each case should be judged
>on its merits. There are times when "all ya gotta do" IS all you have to do.
Nothing is true at all times, including this statement.
If 'each case should be judged on its merits' then it might be concluded
that there is no value in applying the judgments from a different
situation to the current one... the universe becomes 'atomic' and
unpredictable; events are not continuous and experience becomes without
value.
'Well, it didn't work yesterday... but today's a different day, let's try
the same thing again!'
'Well, it worked yesterday... but today's a different day, let's try
something different!'
Your clients might expect something else from your efforts, Mr Dashwood,
but when it comes to writing code I've found that my clients tend to want
the same inputs run through the same code to produce the same results...
not 'each case' to be judged differently.
>
>As I don't share your aversion to this phrase, for the reasons outlined
>above, whether or not some other statement I made seems close to it, is of
>no consequence to me whatsoever.
Hmmmmm... so if each person, by definition, has a different perspective
then to each person the perspective of the same situation is different...
and since every situation is to be judged on its own merits, not on the
merits that someone's perspective brings, there's no sense in considering
what anyone else might bring forward as a view.
DD
| |
| Howard Brazee 2007-05-31, 6:55 pm |
| On Wed, 30 May 2007 19:55:09 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>
>Yes, the VS COBOL II compiler (what I think you mean by "MVS COBOL II) compiler
>supports hex-literals.
I was so glad when that happened (with various compilers at about that
time). I remember looking at some programs on line, and having the
hex characters do funny things to my display. (I'm sure that problem
has been fixed as well). People would put hex characters right in
the code, which weren't very maintainable.
| |
| Howard Brazee 2007-05-31, 6:55 pm |
| On Thu, 31 May 2007 00:22:16 +0000 (UTC), docdwarf@panix.com () wrote:
>This sounds like something back from Ye Oldene Dayse... a programmer is
>allowed two (or more or less) compiles per day because those CPU cycles
>cost big money and all that. What I'm hearing here is that you get some
>code, put your mods in, submit a request to the DBA to compile, get a 12
>back because you fat-fingered CH-NL into CH0NL, change the '0' to a '-',
>submit a request to a DBA to compile, get a 12 back because you typo'd
>PERFORM into PERFROM, change the code, submit a request...
In 1980 I worked in a shop that had everybody run their CoBOL programs
through a syntax checker. We reviewed the output before
re-submitting the programs to the compiler.
| |
|
| In article <tcrt53d6egacnq792uv3jguaou6im92gq6@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Thu, 31 May 2007 00:22:16 +0000 (UTC), docdwarf@panix.com () wrote:
>
[snip]
[color=darkred]
>In 1980 I worked in a shop that had everybody run their CoBOL programs
>through a syntax checker. We reviewed the output before
>re-submitting the programs to the compiler.
Sounds rather similar, Mr Brazee... and just think, about half of 1980 is
more than twenty-seven years ago, give or take a bit.
DD
| |
| Howard Brazee 2007-05-31, 6:55 pm |
| On Thu, 31 May 2007 15:57:19 +0000 (UTC), docdwarf@panix.com () wrote:
>
>Sounds rather similar, Mr Brazee... and just think, about half of 1980 is
>more than twenty-seven years ago, give or take a bit.
How did that happen? Isn't twenty-seven years a significant amount
of time? But it seems so recent...
| |
|
| In article <post53h4jn8oik1b2igprnr7ja5e6o80t0@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Thu, 31 May 2007 15:57:19 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>How did that happen?
Time continued to pass... or something like that. Getting older beats the
alternative, usually.
>Isn't twenty-seven years a significant amount
>of time?
I recall an explanation of the Theory of Relativity as saying 'When you
sit on a hot stove for a minute, it seems like an hour; when you kiss a
pretty girl for an hour, it seems like a minute'.
>But it seems so recent...
That is a Good Thing, Mr Brazee... there are those whose aged brains see
the past as immediate and that can be a horror.
'Where are they? They said they were stepping out for just a minute and
they should be back by now... what happened to them?'
DD
| |
| Howard Brazee 2007-05-31, 6:55 pm |
| On Thu, 31 May 2007 16:44:01 +0000 (UTC), docdwarf@panix.com () wrote:
>I recall an explanation of the Theory of Relativity as saying 'When you
>sit on a hot stove for a minute, it seems like an hour; when you kiss a
>pretty girl for an hour, it seems like a minute'.
When I was ten, a year went by so slowly, kind of as though it was ...
a tenth of a lifetime.
| |
| Alistair 2007-05-31, 6:55 pm |
| On 30 May, 19:41, "gary" <garyi...@yahoo.com> wrote:
> I have to modify an old COBOL program which probably hasn't been touched
> since the mid-90's. And it's probably been almost as long since I've
> touched COBOL. Part of what happens in the program is the setting of some
> printer control codes which are sent to some downstream printers in CICS.
>
> The following snippet of code shows how some of the control codes are
> currently being set. It seems pretty straightforward. For instance, the
> redefinition of CH-FF-BIN with its value of +12 causes the CH-FF field to
> contain X'0C. Simarly, CH-1D-BIN with its value of +29 causes the CH-1D
> filed to contain a X'1D'.
>
> 01 CH-NL-BIN PIC S9(4) COMP VALUE +21.
> 01 FILLER REDEFINES CH-NL-BIN.
> 02 FILLER PIC X.
> 02 CH-NL PIC X.
> 01 CH-FF-BIN PIC S9(4) COMP VALUE +12.
> 01 FILLER REDEFINES CH-FF-BIN.
> 02 FILLER PIC X.
> 02 CH-FF PIC X.
> 01 CH-1D-BIN PIC S9(4) COMP VALUE +29.
> 01 FILLER REDEFINES CH-1D-BIN.
> 02 FILLER PIC X.
> 02 CH-1D PIC X.
> 01 CH-56-BIN PIC S9(4) COMP VALUE +86.
> 01 FILLER REDEFINES CH-56-BIN.
> 02 FILLER PIC X.
> 02 CH-56 PIC X.
> 01 CH-31-BIN PIC S9(4) COMP VALUE +49.
> 01 FILLER REDEFINES CH-31-BIN.
> 02 FILLER PIC X.
> 02 CH-31 PIC X.
>
> My question is this. I need to add a field which would end up containing a
> X'E5'. The decimal equivalent is +229. Since the value of the field is
> 3-digits, will it still "fit" into the PIC X field? Would it look something
> like this?
>
> 01 CH-E5-BIN PIC S9(4) COMP VALUE +229.
> 01 FILLER REDEFINES CH-E5-BIN.
> 02 FILLER PIC X.
> 02 CH-E5 PIC X.
>
> This is some old MVS COBOL II code. Is there actually a better way to be
> performing this function? Is there anything like MOVE X'E5' to CH-E5?
>
> Thank you.
> Gary
Why not just edit the fields with PIC X VALUE '.' where the . is the
hex value (eg E5) using HEX ON in an ISPF edit session? Someone else
mentioned that screens can be upset by this but that is something that
I have not encountered. If you are worried about making the code easy
to understand (self documenting) then add a comment field to show what
the value is. However, the field naming standards you use seem to be
self-documenting.
| |
| William M. Klein 2007-05-31, 6:55 pm |
| Probably true. I snipped before reviewing my post.
--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:f3m3s9$gv9$1@reader2.panix.com...
> In article <2Fs7i.159356$oS7.144347@fe04.news.easynews.com>,
> William M. Klein <wmklein@nospam.netcom.com> wrote:
>
> [snip]
>
>
> I believe that the original poster specified that the target of the +229
> VALUE clause was an S9(4) COMP field which had been REDEFINED into two PIC
> X fields.
>
> DD
>
| |
| William M. Klein 2007-05-31, 6:55 pm |
| As I said in another reply, I think I was in error as I posted after "snipping"
and missed what you were talking about.
I still think that the "hex-notation" is the best solution to this PARTICULAR
problem.
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5c84r7F2vuab1U1@mid.individual.net...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:2Fs7i.159356$oS7.144347@fe04.news.easynews.com...
>
> I was aware of the TRUNC NOTRUNC options but I believe that neither of them
> will affect this - correct me if I'm wrong. The field is defined as 4 digits
> and is binary, a value no greater than 255 is being placed in it. Truncation
> to 4 digits or non-truncation of 5 digits will have no effect on this
> particular case, as far as I can see. I have used exactly this approach on a
> number of installations and never had a problem with it. (Maybe they all had
> the same defaults).
>
> There is no question of a PIC 9(2) field being involved... It is a halfword
> redefined to PIC XX.
>
> I posted because the OP was getting a lot of whys and wherefores when really
> all that was needed was a simple "yes" or "no".
>
> Pete.
>
>
>
>
| |
|
|
|
|
|