LOW-VALUES to a numeric field
Graham Hobbs
I have a field in both a VSAM copybook and a DB2 DCLGEN:
05 fld pic s9(5) comp-3.
It will be a key in a CICS program to reach top of file|table.
'move low-values to fld' will not compile.
So two ways I know of are:
a)
05 fld-r redefines fld pic x(3).
then use 'move low-values to fld-r'
except it could mean copybook changes, bit dodgier in the case of
automatically generated DCLGEN's, so I am generally anti-copybook
doctoring.
b)
'move -99999 to fld'
has flaws: it isn't the lowest of the low, is easier to miscode, is
not the very explicit 'low-values'.
I really would like to just do 'move low-values to fld'. Is there a
solution I don't know about?
Thanks
Graham
Arnold Trembley
Can your field as it is used normally contain negative values? How
about zero?
Without knowing your application I cannot be sure, but I would recommend:
MOVE ZERO TO FLD.
Even if you could find a way to force low-values into a packed decimal
field, that's just inviting a S0C7 abend.
Pete Dashwood
Looks like there isn't :-)
Redefines or the lowest legal value just about covers it.
I was shocked when I read your post because most of the mainframers I know
learned decades ago NEVER to make packed fields key fields, and generally
(since about the mid-eighties, when inter-system communication became a
system design consideration and the cost of storage was dropping
exponentially) to avoid using packed fields at all (except perhaps for
currency)
Sure you can do it, but, as you are finding, there are subtle implications
which are not immediately obvious.
Never mind, you have the situation you have and the best must be made of it.
My vote would be for the -99999 solution.
It lets you use the field legitimately for negative numbers, and has the
least impact on the COPY books.
Pete.
--
"I used to write COBOL...now I can do anything."
riplin
In systems that I use -99999 is not even a low byte value, it is the
highest valid byte value. S9(5) COMP-3 is packed and postsigned. The
only difference between the byte values of +99999 and -99999 is the
final nybble.
ZERO is hex 00000x where x is some value of the sign. -99999 is hex
99999D and +99999 is hex 99999D.
COMP-x fields can only be used where they are used for COMPutations.
Attempting to use these as keys where only the byte value is important
will fail in non-useful ways.
Pete Dashwood
Is that a typo, Richard?
Surely +99999 is hex 99999F or 99999C ?
(IBM mainframes will change the F to a C if the field is used in a
calculation)
>
> COMP-x fields can only be used where they are used for COMPutations.
> Attempting to use these as keys where only the byte value is important
> will fail in non-useful ways.
I agree totally.
William M. Klein
and ask exactly what they are trying to do.
A) Are you trying to set this numeric field to the smallest possible VALID
value - so that you can start a "browse" of the file from the lowest record
forward?
B) Are you trying to set the field to some "invalid" value that can never appear
in a VALID record - to be used as some sort of "flag".
C) something else?
* * * * *
From your statement,
"It will be a key in a CICS program to reach top of file|table"
and ignoring the use of "top" of file/table (rather than beginning), then I
would say that if this field is TRULY a numeric field that should be defined as
COMP-3, then you should simply move -99999 to it. You also need to "understand"
your data to know if this is or is not (ever) a possible valid value for the
field. Your processing will be different depending upon that.
* * * * * *
What you are really looking for, is a new feature in the '02 ANSI/ISO Standard
that is NOT available in any IBM compiler. (I am assuming IBM by uses of "VSAM"
and "DB2" in your original note). In the current ('02 Standard), you can use
the intrinsic functions HIGHEST-ALGEBRAIC and LOWEST-ALGEBRAIC to place the
lowest POSSIBLE VALID value into a numeric field (based on its picture and
usage). This works with signed and unsigned fields and with display, national,
packed-decimal, floating-point, binary, and all other types of fields.
If you are an IBM customer, you can create a "Marketing Request" (via your local
IBM branch) to request that IBM add support for these intrinsic functions into
the "soonest possible' FUTURE version of their compiler. If you don't know how
to do this, but want to, feel free to contact me off-line.
--
Bill Klein
wmklein <at> ix.netcom.com
"Graham Hobbs" <gho...@cdpwise.net> wrote in message
news:te1jb5p6rijuld983...@4ax.com...
HeyBub
> Hello,
>
> I have a field in both a VSAM copybook and a DB2 DCLGEN:
>
> 05 fld pic s9(5) comp-3.
>
> It will be a key in a CICS program to reach top of file|table.
>
> 'move low-values to fld' will not compile.
>
You can (maybe) avoid the copybook problem with
01 Dumx.
02 Dumx-9 pic s9(5) comp-3.
MOVE LOW-VALUES TO DUMX.
...
MOVE DUMX-9 TO fld.
Assuming your compiler doesn't check validity on a non-converting move.
docd...@panix.com
I think the original advice given was, as paraphrased below, very
reasonable.
IT IS USUALLY NOT A VERY GOOD IDEA TO MOVE A NON-NUMERIC VALUE TO A PACKED
NUMERIC (COMP-3) FIELD.
IT IS *SO* USUALLY NOT A VERY GOOD IDEA THAT THE COMPILER WON'T ALLOW YOU
TO DO IN THIS CASE.
If someone's design is so bad that it requires kludging code to get around
compiler rules then maybe the design needs to be revisited... and by a
different designer, one who is not married to the CIO's elderly, ugly
daughter.
Of course... it is not likely that this'll happen. The design has already
been approved by people (who, when pressed, will quite likely and quite
proudly admit to being 'Not Technical') who are convinced they are right.
I would suggest that you plead ignorance... 'I'd love to do it but the
compiler just won't let me and I can't figure out a way around it.'
You'll be ridiculed and the job will be given to someone who will, most
likely, write some 'Look, Mom, I'm a Programmer!' code to get around this
design flaw... and when the whole thing comes crashing down at least you
will have a step or two of remove from it.
(This is how I suggest an employee handles it. As a
consultant/contractor/hired gun I would say 'I refuse to write code that
would allow for such a fundamental flaw to be perpetuated; to do so would
be a violation of my professional ethics.' I would also be prepared to
find another job for such a refusal.)
DD
Howard Brazee
<dash...@removethis.enternet.co.nz> wrote:
>I was shocked when I read your post because most of the mainframers I know
>learned decades ago NEVER to make packed fields key fields, and generally
>(since about the mid-eighties, when inter-system communication became a
>system design consideration and the cost of storage was dropping
>exponentially) to avoid using packed fields at all (except perhaps for
>currency)
I don't use packed nor binary for any data to be stored, but I still
use them in some calculations, where they will never be exported, and
are more efficient. I don't see any downside there.
--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."
- James Madison
Alistair
> Hello,
>
> I have a field in both a VSAM copybook and a DB2 DCLGEN:
>
> 05 fld pic s9(5) comp-3.
>
> It will be a key in a CICS program to reach top of file|table.
I wonder if there is some efficiency implication in using low-values
here? I worked somewhere once where a single high-values record was
added to each VSAM file before loading with the result that the CI and
CA breaks caused a reduction in efficiency when loading data as each
record was inserted before the last (high-values) record.
Graham Hobbs
my machine went down and I lost some replies. One I remember from Bill
Klein asked about context so ...
Scenario is I get copybooks from clients, maybe DB2 maybe VSAM, maybe
numeric keys usually not, some suave some not. I write pgms to put the
table or file online via CICS where browsing up and down the file or
table is required, e.g. entering a new key, top/end of file (tof/eof),
up/down 'n' recs.
In particular tof and eof are vastly simplified by using the lowest or
highest possible value in the startbr command where fld is the key so:
If fld is pic xxx the startbr is
if tof
move low-values to fld and readnext's
else
if eof
move high-values to fld and readprev's
end
.
This is the normal and satisfactory solution albeit based on the usual
situation that files/tables don't have extraneous high/low value recs.
However, if fld is pic 999 or s999 the startbr is
if tof
compute fld = -999 (or 000 if unsigned) and readnext's
else
if eof
compute fld = 999 and readprev's
end
.
It is this numeric method that is 'not as ultimate' because you can't
move low/high vals to a numeric field
UNLESS
there is something I don't know ... very possible.
Because I work with client copybooks I am not interested in adding
redefines stmts. So the solution needs to be in the procedure code.
So other than -999 and +999 for a signed fld or 000 and 999 for an
unsigend field, any other ideas?
Graham
Graham Hobbs
In my reply to Alistair said I'd lost your post - well I found it.
Your A) covers it exactly. Just from purist reasons I can startbr with
GT (greater than) for alpha keys but need GE (greater than or equal)
for numeric keys. The implication to me being, GT produces a single
result, GE is an 'or'.
Yes I am an IBM customer, so small I don't get/afford 'support'. Such
a new feature in COBOL would be a) useful to me for startbr with a
numeric key, b) kind of conform with low/high values in alpha fields,
c) other than top/end of file CICS browsing via a numeric key I can't
think of another use - maybe in batch?
Other posts (and my thanks for such) confirm what I asked can't be
done. For now I will go with the low/high legal value.
Cheers
Graham
slade
>
> - Show quoted text -
Hi Graham,
I'm late to the party (maybe too late), but here goes, anyway:
In the FD for the file, code an additional 01, for e.g. "01 other-def
pic x(nnn)." where nnn = the length of the orig-def you receiv- ed
from the cust.
To set the key to X'00's MOVE LOW-VALUES TO other-def(a:b) where a =
the pos of the key in the rec and b = the len of the key.
If your compiler doesn't support reference modifiaction, please ignore
this post. :-)
Graham Hobbs
Never too late to party Slade! I like it, never thought of it.
E.G.
* This is the users copybook
01 VSAMDATA.
05 FIVER1 PIC X(5).
05 FIVER2 PIC S9(6).
05 FIVER3 PIC S9(5)V9(2) COMP-3.
05 FIVER4 PIC X(5).
* This is what I create - easy to do, doesn't interfere with
* users' copybooks, not as pure as Bill Klein's suggested
* 'new Cobol reequirement', but works for my purposes
01 VSAMDATA-REDEF REDEFINES VSAMDATA.
05 FILLER PIC X(5).
05 FIVER2-A PIC X(6).
05 FIVER3-A PIC X(4).
05 FILLER PIC X(5).
* and then 'move high/low vals to fiver2-a and/or fiver3-a
So now I have two solutions - my 'full' REDEFINES above or reference
mod as you suggest - which raised an interesting point for me because
when I write pgms I have occasionally used reference mod without
thought to compiler capabilities. More food for thought.
Thanks.
Graham
William M. Klein
key field. Although the original poster used that term, it was subsequently made
clear that this was NOT what was really wanted. What was wanted was the ability
to put a value that would be the LOWEST value (to start a "sequential" browse of
a file).
Although "Low-Values would meet such a requirement for an alphanumeric key
field, it does NOT for a key field that is numeric. As the OP acknowledge
moving -999 (for signed) or 000 for unsigned would do this. (Make the number of
"9s" correct for the picture clause).
As I previously said, the current COBOL Standard does have support for this. It
has the HIGH-ALGEBRAIC and LOWEST-ALGEBRAIC intrinsic functions. The OP's
compiler doesn't currently support this, but it is what was mean when the term
"low-values for numeric field" was used.
FYI,
If (unlike the OP) one really did want to move low-values to a key field, then
there is an easy way to do this without any redefines. Given a copybook of:
> 01 VSAMDATA.
> 05 FIVER1 PIC X(5).
> 05 FIVER2 PIC S9(6).
> 05 FIVER3 PIC S9(5)V9(2) COMP-3.
> 05 FIVER4 PIC X(5).
The follow code would do this:
Move Low-Values to VSAMDATA (12:7)
This doesn't do what the OP *wants* but does do what others are trying to get
to.
--
Bill Klein
wmklein <at> ix.netcom.com
"Graham Hobbs" <gho...@cdpwise.net> wrote in message
news:01dvb5tke63394090...@4ax.com...
riplin
wrote:
> Please, PLEASE, stop responding with ways to get "low-values" into the numeric
> key field. Although the original poster used that term, it was subsequently made
> clear that this was NOT what was really wanted. What was wanted was the ability
> to put a value that would be the LOWEST value (to start a "sequential" browse of
> a file).
>
> Although "Low-Values would meet such a requirement for an alphanumeric key
> field, it does NOT for a key field that is numeric. As the OP acknowledge
> moving -999 (for signed) or 000 for unsigned would do this. (Make the number of
> "9s" correct for the picture clause).
Does VSAM differentiate between alphanumeric and numeric parts of a
file key ? If I had an indexed sequential file on my system and a key
had been defined as in the example then I would expect the file system
to treat the key as one 20 character alpha numeric field.
Any negative numbers in the S9(6) DISPLAY NUMERIC or in the COMP-3
field would follow the positive absolute value as the fields are sign
trailing.
So if the file was read sequentially then 'ABCDE00001...' would be
followed by 'ABCDE00000p...' (or whatever -1 was represented as) and
then every other numeric pair of values with the positive of n
followed by the negative of n.
So 'ABCDE99999v..' (or whatever -999999 was) would be the _highest_
value (of the series 'ABCDE...') .
Similarly for the COMP-3 field.
So why, exactly, do you think that using -999.. is useful in any way ?
Howard Brazee
<wmk...@nospam.ix.netcom.com> wrote:
>As I previously said, the current COBOL Standard does have support for this. It
>has the HIGH-ALGEBRAIC and LOWEST-ALGEBRAIC intrinsic functions. The OP's
>compiler doesn't currently support this, but it is what was mean when the term
>"low-values for numeric field" was used.
Knowing the data is always good - but short of that, what would be a
good way to emulate these functions?
William M. Klein
You could create a callable module (user-defined function if you had those),
Then,
Pass it the picture string and usage of the field that you want to receiver
the highest/lowest possible value (Pass this by content - or by reference)
and
Pass it (by reference) the filed that you want to get the high/low value.
In the subroutine, "parse" the picture string and move the correct value to the
field. OBVIOUSLY, this would be semi-tricky for things like
- floating-point (COMP-1/COMP-2 in IBM environments)
- binary fields where ANSI conforming TRUNC isn't turned on - but a Picture
was specified (E.g. IBM TRUNC(OPT) and PIC S9(2) Binary - for example)
* * * * *
I don't know if it would be "useful enough" to create such a routine, but it
would do what the '02 Standard intrinsic functions do.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:d7p1c5tlnub2eson4...@4ax.com...
Pete Dashwood
> Well, ....
>
> You could create a callable module (user-defined function if you had
> those),
> Then,
> Pass it the picture string and usage of the field that you want to
> receiver the highest/lowest possible value (Pass this by content - or
> by reference) and
> Pass it (by reference) the filed that you want to get the high/low
> value.
> In the subroutine, "parse" the picture string and move the correct
> value to the field. OBVIOUSLY, this would be semi-tricky for things
> like - floating-point (COMP-1/COMP-2 in IBM environments)
> - binary fields where ANSI conforming TRUNC isn't turned on - but a
> Picture was specified (E.g. IBM TRUNC(OPT) and PIC S9(2) Binary - for
> example)
> * * * * *
>
> I don't know if it would be "useful enough" to create such a routine,
> but it would do what the '02 Standard intrinsic functions do.
>
>> <wmk...@nospam.ix.netcom.com> wrote:
>>
>>> As I previously said, the current COBOL Standard does have support
>>> for this. It
>>> has the HIGH-ALGEBRAIC and LOWEST-ALGEBRAIC intrinsic functions. The
>>> OP's compiler doesn't currently support this, but it is what
>>> was mean when the term "low-values for numeric field" was used.
>>
>> Knowing the data is always good - but short of that, what would be a
>> good way to emulate these functions?
>>
>> --
>> "In no part of the constitution is more wisdom to be found,
>> than in the clause which confides the question of war or peace
>> to the legislature, and not to the executive department."
>>
>> - James Madison
You could just NOT use packed fields as keys...
That has worked for many installations (including mine :-)) for over thirty
years now...
William M. Klein
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:7ie2ciF...@mid.individual.net...
> William M. Klein wrote:
<snip>
> You could just NOT use packed fields as keys...
>
> That has worked for many installations (including mine :-)) for over thirty
> years now...
>
was given under the assumption that this was a "generic" question on how to do
this; not just for a "key" field.
I totally agree that "key fields" should NOT be packed-decimal or binary.