MVS Packed Decimal with no sign nibble?
newsgroup sponsor
packed decimal, but with no sign nibble. I understand that this is a valid
MVS data type, but I can't figure out what COBOL data type would produce
this field.
Can anyone suggest?
thanks ....
Capomaestro
"newsgroup sponsor" <ad...@bpm.no-ip.net> wrote in message
news:8YudnQLu9tK...@comcast.com...
JerryMouse
Huh? How could a system record numbers for further use without a sign?
Michael Mattias
news:R5udnSJM4tc...@giganews.com...
Only PACKED-DECIMAL (COMP-3) has an explicit sign nibble; and I've seen
enough cases where that was omitted, especially when fields are initialized
with MOVE LOW-VALUE TO dataname instead of MOVE ZERO TO dataname. IIRC,
there's even a compiler option which allows the use of 'unsigned'
PACKED-DECIMAL and automatically treats such values as positive.
All the BINARY types (COMP, COMP-4, COMP-5) uses twos complement to express
'negativity.'
(COMP-1 and COMP-2 don't use sign nibbles, either, but I assume you have
ruled those out already).
--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmat...@talsystems.com
>
>
Francis ANDRE
>
> Huh? How could a system record numbers for further use without a sign?
>
In order to group/subgroup data for computation on a whole group as well as
on the subgroup: For example:
01 TODAY..
05 YEAR PIC 9999 COMP-3.
05 MONTH PIC 99 COMP-3.
05 DAY PIC 99 COMP-3.
01 ADAY REDEFINES TODAY PIC 9(8) COMP-3.
If there were a sign, the redefines as COMP-3 could not work:!
FA
Robert Jones
Have you looked at the hexadecimal representation? If so does it show
two numeric digits per byte? If so, perhaps the next byte to the
right, which in hexadecimal may be a digit followed by the letter C,
D, or F, is the real end of the numeric field. Let us know how you
get on.
Robert
Alistair Maclean
the numerics shuffled half a byte to fill the space at Cambridgeshire
County Council in 1982. We called it Elbradecimal after the analyst who
came up with the idea in order to save a byte of filespace. It was not a
standard IBM data type and we had to code through hoops to get around
it.
In message <8YudnQLu9tK...@comcast.com>, newsgroup sponsor
<ad...@bpm.no-ip.net> writes
--
Alistair Maclean
From the UK tv series "The Kumars at No. 42":
Grandmother Kumar interviewing Patrick Stewart (Captain
Jean-Luc Picard of the Federation Starship Enterprise),
"Why aren't there any Indians in Star Trek?
Don't you need any IT support?"
Frank Swarbrick
>
>>>> Francis ANDRE<franci...@easynet.fr> 12/1/2003 10:04:38 AM >>>
That will not work in any case. You'd end up with 00000F000F000F for ADAY,
which is not valid COMP-3. In other words, a COMP-3 with no sign is
"unsigned", in that the last nibble is x'F' rather than x'C' or x'D'. At
least this is the case for IBM Mainframe COBOL.
Now if there were a *no sign* packed decimal data type this probably would
work, but I don't know if any COBOL has such a thing. Would be kind of nice
for use with online authorization messages sent through VisaNet, because
they use such a data type. Don't know if it's "natural" to whatever
language/compiler they use.
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Ron
like x'1234' instead of x'01234C'? Micro-Focus
supports this as COMP-6 I believe, but not IBM...
at least not directly. I would be easy enough to
manipulate tho. Take a comp-3 field, multiply by 10,
redefine, truncate the last byte, move the rest to
the file in a pic x field. You'd have to do the
reverse of course to read the field.
JerryMouse
So you believe an unsigned COMP-3 field doesn't HAVE a sign? That 12345 in
COMP-3 is 01 23 45 instead of 12 34 5F? That's nuts.
1. Besides, what kind of computation are you going to do on a composite
date? Take the square root, maybe?
2. Let's look: YEAR PIC 9999 COMP-3 = 3 bytes
MONTH PIC 99 = 2 bytes
DAY PIC 99 = 2 bytes
Total TODAY = 7 bytes.
ADAY PIC 9(8) = 5 bytes
Let's lay it out in memory for today: 1 December 2003
02 00 3F 01 2F 00 1F
Where the hell is ADAY? The first five bytes? Nah, one of the digits is
an "F."
Chuck Stevens
"Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
news:bqgevq$21cm94$1...@ID-184804.news.uni-berlin.de...
> Now if there were a *no sign* packed decimal data type this probably would
> work, but I don't know if any COBOL has such a thing. ...
Umm ... yes ...
Unisys MCP/AS COBOL74 and COBOL85 COMPUTATIONAL and COBOL85 PACKED-DECIMAL
only allocate space for a sign if the programmer calls for a sign. For
either USAGE, a PIC 9 item occupies four bits, a PIC 99 eight bits, and so
forth. Elementary items at the same level adjacent in the record
declaration are adjacent, filler bits only occur if a four-bit item precedes
an item that requires byte alignment and doesn't end on a byte boundary.
Personally, I find the idea that memory allocated for a packed-decimal item
actually includes extra space for a sign even when the programmer has
explicitly requested to the contrary (by not specifying a sign in the
PICTURE character-string) not only wasteful but slightly bizarre.
If a particular operating environment isn't capable of dealing with unsigned
packed-decimal data (to say nothing of packed-decimal data that doesn't
begin on a byte boundary), that speaks to the capabilities of that operating
environment and the implementation of COBOL for that operating environment,
not to the language as a whole.
-Chuck Stevens
Frank Swarbrick
Interesting. Thanks for the information. I'd say I'd have to agree that
having a no-sign P-D field not take up a nibble to hold the "sign" is not a
bad idea. I think in the case of the IBM mainframe it has to do with 390
machine language having P-D instructions that depend on the 'sign nibble'
even for an 'unsigned' field.
S Comstock
[snip]
>Interesting. Thanks for the information. I'd say I'd have to agree that
>having a no-sign P-D field not take up a nibble to hold the "sign" is not a
>bad idea. I think in the case of the IBM mainframe it has to do with 390
>machine language having P-D instructions that depend on the 'sign nibble'
>even for an 'unsigned' field.
>
There is no such thing as an unsigned field. If you don't code an 'S'
in your picture, you are implicitly saying it is positive, regardless of
of how the data is physically stored.
IMNHO, anyway.
Kind regards,
-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: st...@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
JerryMouse
> "Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
> news:bqgevq$21cm94$1...@ID-184804.news.uni-berlin.de...
>
>> Now if there were a *no sign* packed decimal data type this probably
>> would work, but I don't know if any COBOL has such a thing. ...
>
> unsigned packed-decimal data (to say nothing of packed-decimal data
> that doesn't begin on a byte boundary), that speaks to the
> capabilities of that operating environment and the implementation of
> COBOL for that operating environment, not to the language as a whole.
It's the hardware. Special circuits exist to handle decimal arithmetic,
specifically packed-decimal numbers.
Jack Sleight
generated this data. As far as I know a "signless" packed decimal is
not a valid data type in MVS and related systems. Is each field length
a multiple of two? Scan the recs and check for non-numeric characters
in these fields.
If so, you might have binary (COMP, COMP-4, COMP-5), not packed
(COMP-3) fields. So, if you have a field that contains leading zero
nibbles, and ends with a "1" nibble and a "5" nibble, the value might
not be "fifteen", but "twenty one" (16+5).
"newsgroup sponsor" <ad...@bpm.no-ip.net> wrote in message news:<8YudnQLu9tK...@comcast.com>...
Richard
> Huh? How could a system record numbers for further use without a sign?
There are plenty of uses for numbers that can not be negative, or
would be invalid if they were negative. Prices, discount rates, even
quantities.
Or are you making some other point ?
bpm admin
nibble. Causing confusion but not grief -- using home-grown Java classes for
conversion, so life is easier without the sign, but its odd trying to figure
out what sent the data [receiving a feed on Solaris via MQ messaging]
"Robert Jones" <rob...@jones0086.freeserve.co.uk> wrote in message
news:fcd09c56.03120...@posting.google.com...
Arnold Trembley
>
> I came across packed decimal data where the sign nibble was dropped and
> the numerics shuffled half a byte to fill the space at Cambridgeshire
> County Council in 1982. We called it Elbradecimal after the analyst who
> came up with the idea in order to save a byte of filespace. It was not a
> standard IBM data type and we had to code through hoops to get around
> it.
As far as I know, IBM S/360 and successors do not support this
natively.
Wasn't this format simply called BCD (Binary Coded Decimal) to
distinguish it from IBM packed-decimal? At least that's what I
learned in school 25 years ago.
Arnold Trembley
01 BCD-WORK-AREA.
05 IBM-COMP-3-FOUR-DIGITS PIC 9(4)V9 COMP-3 VALUE ZERO.
05 BCD-EXTRACT REDEFINES IBM-COMP-3-FOUR-DIGITS.
10 BCD-FOUR-DIGITS PIC X(02).
10 FILLER PIC X.
Move any four-digit integer to IBM-COMP-3-FOUR-DIGITS, its BCD
equivalent is in BCD-FOUR-DIGITS.
To convert two BCD bytes to IBM numeric format first move zero to
IBM-COMP-3-FOUR-DIGITS, then load BCD-FOUR-DIGITS. If
IBM-COMP-3-FOUR-DIGITS is numeric (you don't want a S0C7 abend!), then
you have successfully converted it from BCD. Move it to some integer
field.
With a little work, this logic could be generalized to handle BCD
fields of multiple lengths, with no multiplying or dividing.
Capomaestro
transparency' comes into play. What I believe you are seeing is a codepage
translation (EBCDIC/ASCII) conundrum. Is/are the COMP-3 fields defined in
MQ as 'binary' (numeric) or defaulted to data? MQ will translate x'40' to
x'20' (space = space) and 'C1' to '41' ('A' = 'A'). 0C-9C and 0F-9F will be
translated to whatever is in the codepage mapping.
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.03120...@posting.google.com...
Martin Jones
format 'CRAMMED' and used it extensively for compression of dates and
all sorts of numeric codes. Site standards dictated that all display numeric
fields be an even number of digits. They were then CRAMMED to half their
size for storage on disk. ASM subroutines 'CRAM' and 'UNCRAM' were
provided to convert between, say, X'F8F0F1F0F1F3' to/from X'801013'
which is how we held our dates in the pre Y2K conscious era. The subroutines
took source-field, target field and field-length as arguments.
Of course this was not a native IBM format and all programmers knew this.
(Some programmers preferred to handle conversion themselves using
packed fields and suitable redefinitions with the appropriate divide or
multiply
by 10 to allign the numerics correctly).
We also had crude record level compression on our variable length VSAM
files. All data beyond fixed length keys was scanned and strings of up to
9 chars containing spaces or low-values would be replaced by a single byte
of the
format X'xn' where x=char to be replaced and n=2 - 9 indicating the number
of positions to be substituted. Only spaces and low-values were treated this
way, (think of the leading zeros in packed amounts). From memory there
weren't any binary numeric fields in the record layouts. The value of 'x'
above
was obviously chosen so as not to conflict with the values of high-order
nibbles used for alpha characters. We used to achieve up to 25% reduction
on some of our larger records with lots of Name and address fields etc.
All of this processing would have been put in place in the early seventies
when disk storage was genuinely expensive. (I think my current desktop has
around 20 times the storage that IBM site had in total.)
"Alistair Maclean" <alis...@ld50macca.demon.co.uk> wrote in message
news:xWcJcSB6d7y$Ew...@ld50macca.demon.co.uk...
Judson McClendon
to always require a sign in the first place? Perhaps to sell more memory?
There have always been unsigned (implicitly positive) numeric fields,
such as dates. I've always considered that a peculiar design 'quirk'. Other
mainframe architectures provided unsigned numeric fields.
--
Judson McClendon ju...@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Judson McClendon
>
> There is no such thing as an unsigned field. If you don't code an 'S'
In which case, the sign is redundant, no? Do you write your dates with
a sign? Then why store them that way? This is not a semantics issue.
Why should trillions of bytes of memory and disk space be wasted
worldwide for something that is redundant? If you could calculate the
cost in storage wasted because of that particular nonsense since the
introduction of System/360, it would be staggering.
JerryMouse
> "S Comstock" <scom...@aol.com> wrote:
>>
>> There is no such thing as an unsigned field. If you don't code an 'S'
>> in your picture, you are implicitly saying it is positive ...
>
>
> In which case, the sign is redundant, no? Do you write your dates with
> a sign? Then why store them that way? This is not a semantics issue.
> Why should trillions of bytes of memory and disk space be wasted
> worldwide for something that is redundant? If you could calculate the
> cost in storage wasted because of that particular nonsense since the
> introduction of System/360, it would be staggering.
1. The purist would say: "Dates are signed (A.D. vs. B.C.) with an implicit
sign of A.D." Nevertheless,
2. I don't think dates are considered vectors; they are usually used as
scalars. You can't add two dates, you can't multiply two dates, and so on.
As such, they should not only not have signs but should not be treated in
any way as numeric, including storage.
JerryMouse
No, I'm saying that for arithemetic operations a sign is mandatory.
Donald Tees
In many situations an integer is mandatory. Subscripts for example.
Seems to me strange that an integer is by definition a signed number, on
any platform.
Donald
Judson McClendon
>
> 1. The purist would say: "Dates are signed (A.D. vs. B.C.) with an implicit
> sign of A.D." Nevertheless,
For systems that must deal with those dates, add a sign. :-)
> 2. I don't think dates are considered vectors; they are usually used as
> scalars. You can't add two dates, you can't multiply two dates, and so on.
> As such, they should not only not have signs but should not be treated in
> any way as numeric, including storage.
Other than for saving storage, I agree. Perhaps a 'digital' data type that
provided for packed decimal storage but not math would please you? ;-)
Chuck Stevens
Yes, I know. That's my point. And the fact that an explicitly-unsigned
item nonetheless has to have memory allocated for a sign in one particular
implementation is not, in my view, a pattern worthy of imitation in other
implementations!
Having to allocate space for a sign for any item that you've explicitly
described as unsigned does not make sense to me. Shame on the hardware
designers that haven't managed to overcome this hardware-imposed peculiarity
in the forty-or-so years since it was introduced!
-Chuck Stevens
Judson McClendon
>
> Having to allocate space for a sign for any item that you've explicitly
> described as unsigned does not make sense to me. Shame on the hardware
> designers that haven't managed to overcome this hardware-imposed peculiarity
Amen, Chuck!
S Comstock
>There are plenty of uses for numbers that can not be negative, or
>would be invalid if they were negative. Prices, discount rates, even
>quantities.
Quantities _should_ be signed. The human reality is, inventory in stock might
not match inventory as recorded in the computer record. At least if the value
shows up as negative you have some indication of trouble. If the field were
designed to not allow negative numbers, then you start getting results that are
wierd but that _look_ OK.
Why are so many people upset about the sign nibble? It's a fact of life in IBM
mainframes, it's not going away, memory is cheap today. Get over it. Move on.
JerryMouse
> Richard writes ...
>
>> There are plenty of uses for numbers that can not be negative, or
>> would be invalid if they were negative. Prices, discount rates, even
>> quantities.
>
> Quantities _should_ be signed. The human reality is, inventory in
> stock might not match inventory as recorded in the computer record.
> At least if the value shows up as negative you have some indication
> of trouble. If the field were designed to not allow negative numbers,
> then you start getting results that are wierd but that _look_ OK.
>
> Why are so many people upset about the sign nibble? It's a fact of
> life in IBM mainframes, it's not going away, memory is cheap today.
> Get over it. Move on.
As an aside and as an expert on inventory control, I can tell you that
negative on-hand counts are normal. The most common instance is the company
selling something that has not yet been "received" into the inventory.
Sales, obviously, take highest priority, but the person doing the
"receiving" may not have worked her way down to the packing list or may be
waiting on additional documentation.
So, for a period (minutes to days), the inventory record goes negative. When
the paperwork catches up with reality, all is well.
Francis ANDRE
"Frank Swarbrick" <Frank.S...@efirstbank.com> a écrit dans le message
de news: bqgevq$21cm94$1...@ID-184804.news.uni-berlin.de...
Francis ANDRE
with no quartet bit for the sign.... So ma previous suggestion is working
fine and quite useful....but you are rigth an unsigned packed decimal on IBM
COBOLII HAS the sign nible in which case my suggestion does not work at
all...
By the way, if you specify a data item to be unsigned, I do not see any
reason why the internal representation should have an "invisible"
nibble....that's contrary to the spirit of Cobol where a programmer's should
be aware of alignment and implementation of datas otherwise the redefines or
the renames feature have no foundations... In the time where Cobol was
defined and used, memory space was a stringent constraint...so saving a
quartet of bit could be reasonable for the implementation of unsigned packed
decimal....
FA
"Frank Swarbrick" <Frank.S...@efirstbank.com> a écrit dans le message
de news: bqgevq$21cm94$1...@ID-184804.news.uni-berlin.de...
> >
> >
Richard
First of all, for your original 'numbers', arithmetic operations are
not mandatory. That is there can be numbers independant of such
operations. Dates for example, or many numeric identities: cheque
numbers, phone numbers. For some of these it may be argued that they
should be treated as alpha-numeric, but there is no sign for these.
Even if arithmetic operations are required there is still no need for
an _explicit_ sign for many numbers. Cardinals cannot be negitive, no
sign is required or used.
There is no mandatory requirement for a sign in mathematics, COBOL, or
even [most] hardware. So in what way is it 'mandatory' ?
Francis ANDRE
In C, no subscript could be negative as it starts from 0 to whatever you
need....also C provides unsigned data type that never never goes below 0....
I would suggest for clarity of any discourse to use the term NATURAL for
whatever is zero or positive and INTEGER for a negative/positive domain of
value....(as specified more or less in elementatry mathematic)
"Donald Tees" <donal...@nospam.sympatico.ca> a écrit dans le message de
news: Pr1zb.5393$zf2.8...@news20.bellglobal.com...
Richard
> In many situations an integer is mandatory. Subscripts for example.
Actually an Ordinal is required and it just happens that an integer is
a convenient way of representing one. In some cases, such as Pascal,
it is possible to set up a set of subscripts such that some are
represented by negitive numbers.
> Seems to me strange that an integer is by definition a signed number, on
> any platform.
Integers are by definition positive or negative in mathematics.
But that doesn't mean that numbers must be integers. Nor does it mean
that every computer must treat an aritmetic operation as having or
requiring a sign.
Francis ANDRE
programmation and getting always a date in good format.....You can
add/subtarct quantities of month and/or day and get a consistent global view
of the date to sort/merge historical records!!!
"JerryMouse" <nos...@bisusa.com> a écrit dans le message de news:
J7Cdnb_WgZW...@giganews.com...
> Francis ANDRE wrote:
> >> Huh? How could a system record numbers for further use without a
> >> sign?
> >>
> >
> > In order to group/subgroup data for computation on a whole group as
> > well as on the subgroup: For example:
> >
> > 01 TODAY..
> > 05 YEAR PIC 9999 COMP-3.
> > 05 MONTH PIC 99 COMP-3.
> > 05 DAY PIC 99 COMP-3.
> > 01 ADAY REDEFINES TODAY PIC 9(8) COMP-3.
> >
> > If there were a sign, the redefines as COMP-3 could not work:!
>
> So you believe an unsigned COMP-3 field doesn't HAVE a sign? That 12345 in
> COMP-3 is 01 23 45 instead of 12 34 5F? That's nuts.
>
> 1. Besides, what kind of computation are you going to do on a composite
> date? Take the square root, maybe?
>
> 2. Let's look: YEAR PIC 9999 COMP-3 = 3 bytes
> MONTH PIC 99 = 2 bytes
> DAY PIC 99 = 2 bytes
>
> Total TODAY = 7 bytes.
>
> ADAY PIC 9(8) = 5 bytes
>
> Let's lay it out in memory for today: 1 December 2003
> 02 00 3F 01 2F 00 1F
>
> Where the hell is ADAY? The first five bytes? Nah, one of the digits
is
> an "F."
>
>
>
>
Capomaestro
chronologically-challenged group.
To the original subject then,
Because the MQ message is moving between platforms, the issue of 'data
transparency' comes into play. What I believe you are seeing is a codepage
translation (EBCDIC/ASCII) conundrum. Is/are the COMP-3 fields defined in
MQ as 'binary' (numeric) or defaulted to data? MQ will translate x'40' to
x'20' (space = space) and 'C1' to '41' ('A' = 'A'). 0C-9C and 0F-9F will be
translated to whatever is in the codepage mapping at those points.
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.03120...@posting.google.com...
> "JerryMouse" <nos...@bisusa.com> wrote
>
> > Huh? How could a system record numbers for further use without a sign?
>
Judson McClendon
> The Bull GCOS7 COBOL supports this feature ...
So, Bull is still around? I worked for Burroughs (now part of Unisys)
back in the 70's. At that time Burroughs relabeled and sold some Bull
card punch equipment. Describing it as junk would be unfair to 'junk'.
Only an idiot salesman at Burroughs would try to sell the things to a
Burroughs mainframe account, because the Bull equipment was so
terrible it could jeopardize the whole account. The customers would
ALWAYS return the Bull punches as soon as the contract permitted,
even sooner if possible. I'm not kidding, everyone at Burroughs field
level hated the things bitterly. The person at Burroughs headquarters
who made that deal was surely fired. I hope Bull is doing a better job
these days. :-)
arnb
> Received a download file from an MVS system. Have a field that appears to be
> packed decimal, but with no sign nibble. I understand that this is a valid
> MVS data type, but I can't figure out what COBOL data type would produce
> this field.
>
> Can anyone suggest?
>
> thanks ....
>
>
>
field is 4 bytes of packed data with no sign, do the following
in file definition
03 file-field pic x(4).
in working storage
.
03 worked-packed pic s9(8)v9 usage comp-3 value zero.
03 worked-packedx redefines work-packed pic x(5).
03 the-number pic s9(9) comp-3.
In procedure division
to make the data useable
move file-field to worked-packedx (1:4)
* manipulate work-packed as needed for example to drop the sign
move worked-packed to the-number
if you want to generate such a field
move 234234 to worked-packed
move worked-packedx to file-field
arnb
> On or about 12/1/2003 7:52 AM, it came to pass that newsgroup sponsor
> wrote:
>
>> Received a download file from an MVS system. Have a field that appears
>> to be
>> packed decimal, but with no sign nibble. I understand that this is a
>> valid
>> MVS data type, but I can't figure out what COBOL data type would produce
>> this field.
>>
>> Can anyone suggest?
>>
>> thanks ....
>>
>>
>>
> MVS normally won't create this but can be easily made to work with it.
> If your field is 4 bytes of packed data with no sign, do the following
>
> in file definition
> 03 file-field pic x(4).
>
> in working storage
>
> .
> 03 worked-packed pic s9(8)v9 usage comp-3 value zero.
> 03 worked-packedx redefines work-packed pic x(5).
> 03 the-number pic s9(9) comp-3.
>
>
> In procedure division
> to make the data useable
> move file-field to worked-packedx (1:4)
> * manipulate work-packed as needed for example to drop the sign
typing to fast without editing... that should have read as to drop the low order
byte,
Judson McClendon
You can get the same thing when errors are made in inventory control.
All of us who have dealt with inventory systems know that quantities
may be negative for various reasons. However, where is the need for
a sign on a telephone number or employee number? They do not even
represent quantities. This is why COBOL, most programming languages,
and most hardware in the world, other than IBM mainframes, supports
BOTH signed and unsigned quantities. Nothing that has been stated in
this thread (or that CAN be said) changes the fact that appending a sign
that is always fixed is a complete waste of resources. We realize it is
a reality for the IBM world, but it is still a pointless waste that IBM
could (fact) and should (the opinion of most non-IBM'ers) have
remedied long ago (since IBM sells storage, they have no interest in
correcting this). What IBM does is simply what IBM does, no more,
no less. Specific need and mathematical convention hundreds of years
old dictate the need for a sign or not. IBM is simply out of step. It was
designed into the 360 over 40 years ago to save circuitry (cost), or
conceivably to sell more memory, certainly not from any mathematical
necessity. IBM has continued this unnecessary convention through
subsequent generations of hardware. There is really nothing else to be
said on the issue; certainly nothing that would change these facts. :-)
Howard Brazee
On 1-Dec-2003, "Francis ANDRE" <franci...@easynet.fr> wrote:
> In order to group/subgroup data for computation on a whole group as well as
> on the subgroup: For example:
>
> 01 TODAY..
> 05 YEAR PIC 9999 COMP-3.
> 05 MONTH PIC 99 COMP-3.
> 05 DAY PIC 99 COMP-3.
> 01 ADAY REDEFINES TODAY PIC 9(8) COMP-3.
>
> If there were a sign, the redefines as COMP-3 could not work:!
Are you claiming that it works without a sign? Does it even compile cleanly?
We still have the sign nibble, only it is an unsigned sign nibble.
Howard Brazee
files was to move unsigned numbers to signed numbers and back before comparing
them to new data. It seems that IBM changed how it stored unsigned data.
This was over 20 years ago.
Howard Brazee
On 1-Dec-2003, Alistair Maclean <alis...@ld50macca.demon.co.uk> wrote:
> I came across packed decimal data where the sign nibble was dropped and
> the numerics shuffled half a byte to fill the space at Cambridgeshire
> County Council in 1982. We called it Elbradecimal after the analyst who
> came up with the idea in order to save a byte of filespace. It was not a
> standard IBM data type and we had to code through hoops to get around
Was it worth the effort?
William M. Klein
universal) vendor extension for unsigned packed-decimal numeric fields.
Although I "grew up" in the IBM mainframe COBOL environment where a sign-nibble
was ALWAYS allocated (so even number of digit unsigned packed-decimal fields
were a "no-no"). However, I have always thought that this was a "silly" design.
I am NOT certain, however, that I (personally) would be "happy" with a COBOL
system that supported packed-decimal items that did NOT start on byte
boundaries - UNLESS that system also supported "less-than-a-byte" COBOL data
types - which is certainly NOT a part of any COBOL Standard (that I am aware of)
before the 2002 Standard.
I believe that earlier Standards "allow" for slack nibbles, but certainly do not
"require" them, i.e.
01 One-or-two-Bytes.
05 Nibble-1 Pic 9 Packed-Decimal.
05 Nibble-2 Pic 9 Packed-Decimal.
seems much more COBOL-intuitive to me as "two" bytes, not "one". OTOH, I
suspect the '85 Standard would ALLOW it to be a single byte group item.
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles...@unisys.com> wrote in message
news:bqgk4d$c20$1...@si05.rsvl.unisys.com...
>
> "Frank Swarbrick" <Frank.S...@efirstbank.com> wrote in message
> news:bqgevq$21cm94$1...@ID-184804.news.uni-berlin.de...
>
> > Now if there were a *no sign* packed decimal data type this probably would
> > work, but I don't know if any COBOL has such a thing. ...
>
> Umm ... yes ...
>
> Unisys MCP/AS COBOL74 and COBOL85 COMPUTATIONAL and COBOL85 PACKED-DECIMAL
> only allocate space for a sign if the programmer calls for a sign. For
> either USAGE, a PIC 9 item occupies four bits, a PIC 99 eight bits, and so
> forth. Elementary items at the same level adjacent in the record
> declaration are adjacent, filler bits only occur if a four-bit item precedes
> an item that requires byte alignment and doesn't end on a byte boundary.
>
> Personally, I find the idea that memory allocated for a packed-decimal item
> actually includes extra space for a sign even when the programmer has
> explicitly requested to the contrary (by not specifying a sign in the
> PICTURE character-string) not only wasteful but slightly bizarre.
>
> If a particular operating environment isn't capable of dealing with unsigned
> packed-decimal data (to say nothing of packed-decimal data that doesn't
> begin on a byte boundary), that speaks to the capabilities of that operating
> environment and the implementation of COBOL for that operating environment,
> not to the language as a whole.
>
> -Chuck Stevens
>
>
JerryMouse
Presumably, IBM is (was) working with the quaint concept that when you use a
number you intend to do arithmetic with it. The cases you mentioned,
telephone number and employee number are not numbers, but names using digits
as the characters. Remember when telephone numbers used alphabetics? Stick
those in your packed field! And no, you can't convert "PLaza 2000" to
numbers, store it, then reconstruct it. Because in another location it might
be "PLumbo 2000."
Judson McClendon
> I am NOT certain, however, that I (personally) would be "happy" with a COBOL
> system that supported packed-decimal items that did NOT start on byte
> boundaries - UNLESS that system also supported "less-than-a-byte" COBOL data
> types - which is certainly NOT a part of any COBOL Standard (that I am aware of)
> before the 2002 Standard.
Hello, Bill. Where in the COBOL 85/89 standard does it specify how
many 'bytes' or 'half-bytes' a particular data format must use? :-)
Judson McClendon
>
> Presumably, IBM is (was) working with the quaint concept that when you use a
> number you intend to do arithmetic with it.
How does that change the fact that adding a 'sign' that is permanently fixed
to a numeric field is redundant? Is it so hard to accept that an unsigned
numeric field is implicitly positive if used in math? Are computer designers
so obtuse they can't design hardware that does arithmetic without actually
'seeing' an explicit sign? If so, only IBM engineers seem to be so impaired.
When you were in school did they teach that you MUST write '+' beside a
positive number or you could not possibly do arithmetic on it? :-)
> The cases you mentioned,
> telephone number and employee number are not numbers, but names using digits
> as the characters.
Correct, so why should they have a sign? Do you append a sign to your name? ;-)
We use packed decimal fields in these cases purely for storage efficiency,
and that is why COBOL permits you to declare an unsigned numeric field in
the first place. If you don't need the 'S', why would you need the 4 bit 'sign'?
> Remember when telephone numbers used alphabetics? Stick
> those in your packed field! And no, you can't convert "PLaza 2000" to
> numbers, store it, then reconstruct it. Because in another location it might
> be "PLumbo 2000."
You would not use a numeric field to store those, so 'sign' is irrelevant.
That doesn't affect other 'identifying' numeric fields like employee numbers,
part numbers or purely numeric G/L account numbers. There have always
been numeric items that can never be negative or that do not represent scalar
values. All of us have worked on computer systems with lots of fields that
were numeric but could never be negative. Why in the world anyone would
think it necessary to append a fixed 'sign' to each of these is beyond me. Any
'sign' that is permanently fixed is redundant. How can that not be blindingly
obvious to everyone? Are your minds so brainwashed with the IBM mantra
that you cannot think outside that frame of reference? Really now, I know
you folks are far to smart to be confused by this! Admit it, you're just
kidding us, right? :-)
docd...@panix.com
JerryMouse <nos...@bisusa.com> wrote:
[snip]
>Remember when telephone numbers used alphabetics? Stick
>those in your packed field! And no, you can't convert "PLaza 2000" to
>numbers, store it, then reconstruct it. Because in another location it might
>be "PLumbo 2000."
Ahhhhh, for the Oldene Dayse... when a telephone-number could be MUrray
Hill-7 or PEnnsylvania-6 such as *ten* telephone-numbers cannot, today!
(... and at least in the USA they *cannot*, today, since the recent
alterations which allow for the second digit of exchanges to be zero or
one.)
DD
Judson McClendon
That's because the IBM PC used an Intel CPU. The IBM System/360 family
and it's descendents and clones are the only CPUs I know of that cannot store
a number without a sign. It may seem strange to IBM-only folks, but the rest
of the computer industry has always known that IBM has always designed
somewhat inefficient computer architectures, both hardware and software.
I'm not IBM bashing, it's the honest truth. I'm sure most of the people here
who have had extensive IBM and non-IBM experience will agree with me.
It has always been incredible to me that IBM mainframe users seem content
to jump through so many hoops that other vendors do not require. Just one
typical example: Way back in the early 70's a knowledgeable person could
walk into any Burroughs mainframe shop with no online configuration at
8AM, find a reasonably small (say 5 lines & 30 stations) configuration on
their desk, and have the system software up and running by noon, ready to
run online applications, without interrupting batch processing to do it. Do
any of you remember what it took back then to do that on 'IBM iron'? :-)
Howard Brazee
On 3-Dec-2003, "JerryMouse" <nos...@bisusa.com> wrote:
> Presumably, IBM is (was) working with the quaint concept that when you use a
> number you intend to do arithmetic with it. The cases you mentioned,
> telephone number and employee number are not numbers, but names using digits
> as the characters. Remember when telephone numbers used alphabetics? Stick
> those in your packed field! And no, you can't convert "PLaza 2000" to
> numbers, store it, then reconstruct it. Because in another location it might
> be "PLumbo 2000."
Or SKimbo 2000.
Howard Brazee
On 4-Dec-2003, "Judson McClendon" <ju...@sunvaley0.com> wrote:
> > I converted programs from IBM DOS to IBM OS. One thing we did when reading
> > old
> > files was to move unsigned numbers to signed numbers and back before
> > comparing
> > them to new data. It seems that IBM changed how it stored unsigned data.
> > This was over 20 years ago.
>
> That's because the IBM PC used an Intel CPU.
That conversion was made before Intel and the PC.
> Way back in the early 70's a knowledgeable person could
> walk into any Burroughs mainframe shop with no online configuration at
> 8AM, find a reasonably small (say 5 lines & 30 stations) configuration on
> their desk, and have the system software up and running by noon, ready to
> run online applications, without interrupting batch processing to do it. Do
> any of you remember what it took back then to do that on 'IBM iron'? :-)
Just compare WFL with JCL.
Chuck Stevens
two telephones in the building, one for the hotel itself and a pay phone in
a booth for the guests. The telephone number for the hotel was 141 (and
yes, the phone had a crank). The telephone number for the pay phone was
9501. All calls went through the operator. The idea of having a prefix
was way too uptown for this place; at this point in history that was for Big
Towns like San Antonio.
Once, my aunt called my mother person-to-person from New York at the hotel.
The operator knew my mother had gone to the movies that afternoon. The
first clue my Aunt had of this was when the person answering the phone said
"Plaza Theater" instead of "Kendall Inn". My aunt was absolutely amazed
when my mother came to the phone less than a minute later.
When we sold the hotel in 1954, we moved to an area that actually had an
automated exchange, and all the numbers were fixed at five digits (ours was
5-3596). It was some years later that they added the MYrtle prefix to our
number, increasing it to seven digits.
-Chuck Stevens
<docd...@panix.com> wrote in message news:bqnebo$kll$1...@panix1.panix.com...
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>My family owned and ran a small hotel in Texas from 1946 to 1954. We had
>two telephones in the building, one for the hotel itself and a pay phone in
>a booth for the guests. The telephone number for the hotel was 141 (and
>yes, the phone had a crank).
Who're you calling a crank, youngster? Ding-blasted whippersnappers...
show some respect to your elders! Go fetch me something to beat you
with... oooooohh, durn this lumbago!
DD
Judson McClendon
>
> On 4-Dec-2003, "Judson McClendon" <ju...@sunvaley0.com> wrote:
>
> > > I converted programs from IBM DOS to IBM OS. One thing we did when reading
> > > old
> > > files was to move unsigned numbers to signed numbers and back before
> > > comparing
> > > them to new data. It seems that IBM changed how it stored unsigned data.
> > > This was over 20 years ago.
> >
> > That's because the IBM PC used an Intel CPU.
>
> That conversion was made before Intel and the PC.
Sorry, you meant the OLD OLD IBM DOS. :-)
> > Way back in the early 70's a knowledgeable person could
> > walk into any Burroughs mainframe shop with no online configuration at
> > 8AM, find a reasonably small (say 5 lines & 30 stations) configuration on
> > their desk, and have the system software up and running by noon, ready to
> > run online applications, without interrupting batch processing to do it. Do
> > any of you remember what it took back then to do that on 'IBM iron'? :-)
>
> Just compare WFL with JCL.
I started to do that, but didn't want to be too hard on the poor IBM'ers. :-)
WFL (WorkFlow Language) is a high level ALGOL type job control
language on Burroughs/Unisys mainframes that is to JCL as COBOL is
to Sanskrit. Come to think of it, Sanskrit makes JCL looks like Sanskrit. ;-)
Howard Brazee
On 4-Dec-2003, "Judson McClendon" <ju...@sunvaley0.com> wrote:
> > Just compare WFL with JCL.
>
> I started to do that, but didn't want to be too hard on the poor IBM'ers. :-)
>
> WFL (WorkFlow Language) is a high level ALGOL type job control
> language on Burroughs/Unisys mainframes that is to JCL as COBOL is
> to Sanskrit. Come to think of it, Sanskrit makes JCL looks like Sanskrit. ;-)
WFL was so direct and easy, it was in a class of its own.
That said, I don't know if I enjoyed using DCL on the VAX more. DEC seemed to
understand the future of distributed processing better than anybody else - too
bad about Digital.
Richard
> Richard writes ...
>
> >There are plenty of uses for numbers that can not be negative, or
> >would be invalid if they were negative. Prices, discount rates, even
> >quantities.
>
> Quantities _should_ be signed. The human reality is, inventory in stock might
> not match inventory as recorded in the computer record. At least if the value
> shows up as negative you have some indication of trouble. If the field were
> designed to not allow negative numbers, then you start getting results that are
> wierd but that _look_ OK.
'Stock on hand' is not a quantity that is always positive. However
that does not mean that there are not quantitities that are invalid if
negative.
> Why are so many people upset about the sign nibble? It's a fact of life in IBM
> mainframes, it's not going away, memory is cheap today. Get over it. Move on.
1) I do not use IBM Mainframes, never have, probably never will.
2) I almost never use packed decimal so sign nibbles are irrelevant to
me.
3) The issue was whether it was _mandatory_ for a number to have a
sign. It isn't. And whether it can take place in arithmetic
operations without one. It can. If it cannot on IBM mainframes, then
that is a limitation of those machines, not of 'numbers' or
'arithmetic operations'.
Hugh Candlin
>
> > Richard writes ...
> >
> > >There are plenty of uses for numbers that can not be negative, or
> > >would be invalid if they were negative. Prices, discount rates, even
> > >quantities.
> >
> > Quantities _should_ be signed. The human reality is, inventory in stock might
> > not match inventory as recorded in the computer record. At least if the value
> > shows up as negative you have some indication of trouble. If the field were
> > designed to not allow negative numbers, then you start getting results that are
> > wierd but that _look_ OK.
>
> 'Stock on hand' is not a quantity that is always positive.
Yes, it is. QOH cannot go below zero unless you have a logic error.
You either have stock on the shelf, or you don't. It isn't like a bank account,
where you can sign up for overdraft protection.
QOH is not the same as [Quantity-on-hand less Inventory Demand],
which can be a negative value.
Binyamin Dissen
:>Richard <rip...@Azonic.co.nz> wrote in message news:217e491a.03120...@posting.google.com...
:>> scom...@aol.com (S Comstock) wrote
:>> > Richard writes ...
True quantity on hand cannot go negative.
Recorded QOH however can go negative if the received goods were not properly
recorded or not recorded in a timely way.
:>QOH is not the same as [Quantity-on-hand less Inventory Demand],
:>which can be a negative value.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
James J. Gavan
Richard wrote:
>
> 'Stock on hand' is not a quantity that is always positive. However
> that does not mean that there are not quantitities that are invalid if
> negative.
The *joys* of inventory control in Fashions and Fashion accessories.
(1) :
Manageress : phones Central Buying in Wigmore Street, near Selfridges.
"Hello Mr. Trimble. Why do you keep sending us Blue raincoats ?".
Trimble : "Because that's your best seller".
Manageress : "No its not we are selling more of the Bright Yellow. Here are the
figures....... The Blue isn't moving at the same rate".
Trimble : "Oh my gawd ! Here we are trying to save money, getting the Manufacturer to
ticket (Kimball Tag) the items. They've obviously mixed up the colour codes !".
(2)
New system going in to stock count wool (knitting yarns). Yours truly keeps a
watching brief as system starts. One store tells us they have 1,902 of X...., 1,903
of Y.... etc. Jeez ! They have enough stock for the whole group ! I phone.
JJG : "Are you sure about the quantities you have of 1,902, 1,903 etc....".
Lady : (Swear she had to be a 105 !). "Well dear. I've only been working here for a
month and those are the numbers shown on the labels".
JJG : (Gently). "You have the descriptions and *our* codes printed on your stock
count sheets. It's not the manufacturer's numbers we are after but the number of
balls of wool you have on the shelves/displays, by make and colour".
Jimmy
William M. Klein
character.
--
Bill Klein
wmklein <at> ix.netcom.com
"Judson McClendon" <ju...@sunvaley0.com> wrote in message
news:20031204074130.899$u...@news.newsreader.com...
Jack Sleight
because they want to sell more storage. Yet they introduced packed dec
in the first place to reduce the use of storage. Huh?
Regards, Jack.
"JerryMouse" <nos...@bisusa.com> wrote in message news:<g7-dnbS9jf-...@giganews.com>...
Jack Sleight
Jack.
"Howard Brazee" <how...@brazee.net> wrote in message news:<bqniqt$bib$1...@peabody.colorado.edu>...
Peter E. C. Dashwood
I have posted several responses to your messages here but they are
apparently not being echoed in North America.
The whole thread is just becoming silly so I'm posting this via GOOGLE
in the hope that you can read it.
specific comments below...
"Judson McClendon" <ju...@sunvaley0.com> wrote in message
news:20031203100056.678$U...@news.newsreader.com...
>
> You can get the same thing when errors are made in inventory control.
> All of us who have dealt with inventory systems know that quantities
> may be negative for various reasons. However, where is the need for
> a sign on a telephone number or employee number? They do not even
> represent quantities. This is why COBOL, most programming languages,
> and most hardware in the world, other than IBM mainframes, supports
> BOTH signed and unsigned quantities.
So does IBM but you either cannot or will not see it.
> Nothing that has been stated in
> this thread (or that CAN be said) changes the fact that appending a sign
> that is always fixed is a complete waste of resources.
Maybe you can't see my posts...(I have had trouble in the past getting
messages echoed to North America).
The above is simply untrue. IBM mainframes DO allow unsigned numeric
fields
and they CAN be used in Arithmetic. I covered this (in detail) in
response
to your previous post, where you made the same nonsensical claim.
Here is a copy of the response:
========================= Quote ============================
"Judson McClendon" <ju...@sunvaley0.com> wrote in message
news:20031202074525.298$Y...@news.newsreader.com...
> Have you ever wondered why the original IBM 360 series was designed
> to always require a sign in the first place?
It wasn't. The original System 360, designed by Gene Amdahl, had no
packed
decimal. It was a pure binary machine, intended for (mainly)
scientific
applications. It utilised up to 64 bit (doubleword) binary, or
floating
point, or external decimal (which was converted to binary for
calculations).
IBM realised that there was a pretty good commercial market for this
system
to replace the ageing 1400 series but it needed to be able to handle
decimal
arithmetic, without using floating point, so that monetary amounts
could be
guaranteed.
Amdahl's architecture used Read Only Storage (ROS) to contain the
instruction set and this was a revolutionary concept at the time (in
effect
it had a "soft" instruction set that later came to be known as
"firmware").
By adding more punched mylar cards to the ROS, it was possible to
implement
the decimal instruction set which gave us packed decimal. (This was an
option on early 360s but became standard on later models, and
incorporated
into a special firmware box on 370).
The point you seem to be missing here Judson, is that the sign was
necessary
to ensure integrity. Machines in those days were notoriously
unreliable.
System 360 had one of the best reliability track records of any
machine
available. It simply refused to process bad data. S0c7, S0c4,
(although many
programmers who had worked on other hardware (self included)
complained bitterly about them),DID ensure that wrong results were not
obtained. Packed fields containing invalid signs simply stopped the
program.
It is also important to remember that you didn't HAVE to use Packed.
External decimal (PIC 99999... in COBOL) was available and did not
require a
sign.(It contained a sign but this was indistinguishable from the
unsigned
form of the number, and did NOT require "extra" storage).
If you had truly unsigned numeric data (and I think dates are
arguable; personally, I would never store dates as packed...), there
was nothing to stop you holding it as external or binary or floating
point. Your
"point" about the storage wasted because of the requirement for packed
fields to have a sign, is just not valid. If storage WAS wasted it was
because of bad analysis and design (that can happen on ANY platform),
and
not specifically because of poor architecture on S360.
> Perhaps to sell more memory?
Nope. Not at all. Memory (being hand made) was certainly expensive but
one
of the reasons for implementing packed in the first place, was to SAVE
memory (and space on external media...the less data on a tape, the
quicker
it could be passed).
> There have always been unsigned (implicitly positive) numeric fields,
> such as dates. I've always considered that a peculiar design 'quirk'.
> Other mainframe architectures provided unsigned numeric fields.
So did S360. (external decimal).
By simply looking at the sign nibble of a packed field in a dump you
could
tell immediately whether the field had ever had arithmetic done on it,
and
whether it was intended to be signed or expected to be positive.
When I first encountered this architecture I thought it was "odd".
After 6
months of using it, I realised it was a stroke of genius.
Having said that, in today's IT world, it is an archaic representation
for
which there is no real need, and should be avoided. I can't remember
the
last time I designed a system that used it, but it was certainly more
than
20 years ago.
=========================== End Quote ============================
Packed decimal is NOT the ONLY numeric format available on IBM
hardware.
> We
Plural Majestatus est?
> realize it is
> a reality for the IBM world, but it is still a pointless waste that IBM
> could (fact) and should (the opinion of most non-IBM'ers)
Funny, as a non-IBMer I saw no survey from you...<G>
> have
> remedied long ago (since IBM sells storage, they have no interest in
> correcting this).
I can't believe you are writing such rubbish. They haven't "corrected"
it because it ISN'T broken!
As for using it as a device to sell more storage, get with the
program! Packed decimal was implemented in the days when storage cost
an arm and a leg.
One of its primary purposes was to SAVE storage!! (See above)
> What IBM does is simply what IBM does, no more,
> no less. Specific need and mathematical convention hundreds of years
> old dictate the need for a sign or not. IBM is simply out of step. It was
> designed into the 360 over 40 years ago to save circuitry (cost),
Nope. It was an additional cost for the people who ordered 360s
intended for commercial processing.
> or
> conceivably to sell more memory,
Unbelievable!
> certainly not from any mathematical
> necessity. IBM has continued this unnecessary convention through
> subsequent generations of hardware. There is really nothing else to be
> said on the issue; certainly nothing that would change these facts. :-)
So your mind is closed on it, right Judson? <G>
I agree with you (oddly enough...<G>) that Packed Decimal is a format
we
could well do without, but not for the reasons you state.
Simply because it IS platform specific and there is no need for it
nowadays.
It is available currently because of "backward compatibility". There
are
no good arguments I can think of for continuing to use it, and I don't
know anybody who designs new systems incorporating it.
INTERNALLY, IBM mainframes can (and do...) continue using it, but I
see no need for it to be visible to users, at least when developing
new systems.
To suggest it is being continued so IBM can sell more memory, is
simply pathetic...
more comments below...
"Judson McClendon" <ju...@sunvaley0.com> wrote in message news:<20031204082440.078$7...@news.newsreader.com>...
> "JerryMouse" <nos...@bisusa.com> wrote:
> >
> > Presumably, IBM is (was) working with the quaint concept that when you use
> > a number you intend to do arithmetic with it.
>
> How does that change the fact that adding a 'sign' that is permanently fixed
> to a numeric field is redundant? Is it so hard to accept that an unsigned
> numeric field is implicitly positive if used in math?
No, and there are alternative formats to Packed Decimal, available on
IBM mainframes. The fact that the packed architecture includes an
intrinsic sign is irrelevant. That is simply the way it works. It was
designed by a man whose name is (rightfully) legend, as an efficient
way to implement decimal arithmetic on a binary machine and save
expensive bytes at the same time.
> Are computer designers
> so obtuse they can't design hardware that does arithmetic without actually
> 'seeing' an explicit sign? If so, only IBM engineers seem to be so impaired.
How does producing something that is efficient, accurate, and self
checking, demonstrate "impairment"?
> When you were in school did they teach that you MUST write '+' beside a
> positive number or you could not possibly do arithmetic on it? :-)
>
No, but there were many other conventions they didn't teach us
either...
(Like...
The wife is ALWAYS right.
Kids will ALWAYS do what you expressly tell them not to (sooner or
later...).
Insurance sucks.
And so on...)
> > The cases you mentioned,
> > telephone number and employee number are not numbers, but names using digits
> > as the characters.
>
> Correct, so why should they have a sign? Do you append a sign to your name? ;-)
I sign my name all the time <G>
> We use packed decimal fields in these cases purely for storage efficiency,
> and that is why COBOL permits you to declare an unsigned numeric field in
> the first place. If you don't need the 'S', why would you need the 4
> bit 'sign'?
>
If you don't need the sign and it offends you so mightily, use
external decimal.
> > Remember when telephone numbers used alphabetics? Stick
> > those in your packed field! And no, you can't convert "PLaza 2000" to
> > numbers, store it, then reconstruct it. Because in another location
> > it might
> > be "PLumbo 2000."
>
> You would not use a numeric field to store those, so 'sign' is irrelevant.
> That doesn't affect other 'identifying' numeric fields like employee numbers,
> part numbers or purely numeric G/L account numbers. There have always
> been numeric items that can never be negative or that do not represent scalar
> values. All of us have worked on computer systems with lots of fields that
> were numeric but could never be negative. Why in the world anyone would
> think it necessary to append a fixed 'sign' to each of these is beyond me.
Yes, apparently it is <sigh>...
Pete.
Jim Reinhart
"newsgroup sponsor" <ad...@bpm.no-ip.net> wrote:
> Received a download file from an MVS system. Have a field that appears to be
> packed decimal, but with no sign nibble. I understand that this is a valid
> MVS data type, but I can't figure out what COBOL data type would produce
> this field.
>
> Can anyone suggest?
>
> thanks ....
>
>
>
MVS COBOL from ANS to zOS
05 ABC PIC 9 COMP-3 VALUE +1. This is an unsigned packed decimal number
the internal representation would be X'1F'
MOVE -1 TO ABC.
the internal representation would be X'1F' regardless of positive or
negative.
If it was signed, the statement would read
05 ABC PIC S9 COMP-3 VALUE +1.
the internal representation would be X'1C' for positive
MOVE -1 TO ABC.
the internal representation would be X'1D' for negative
Everything that is needed to know is in the IBM redbooks for Zone Decimal
(DISPLAY), PACKED-DECIMAL (COMP-3), BINARY (COMP) and FLOAT (COMP-1,
COMP-2).
Hugh Candlin
Binyamin Dissen <post...@dissensoftware.com> wrote in message news:qovusv8nt1e817fkg...@4ax.com...
> On Thu, 04 Dec 2003 18:18:23 GMT "Hugh Candlin" <n...@spam.com> wrote:
>
> :>Richard <rip...@Azonic.co.nz> wrote in message news:217e491a.03120...@posting.google.com...
>
> :>> scom...@aol.com (S Comstock) wrote
>
> :>> > Richard writes ...
>
> :>> > >There are plenty of uses for numbers that can not be negative, or
> :>> > >would be invalid if they were negative. Prices, discount rates, even
> :>> > >quantities.
> :>> >
> :>> > Quantities _should_ be signed. The human reality is, inventory in stock might
> :>> > not match inventory as recorded in the computer record. At least if the value
> :>> > shows up as negative you have some indication of trouble. If the field were
> :>> > designed to not allow negative numbers, then you start getting results that are
> :>> > wierd but that _look_ OK.
>
> :>> 'Stock on hand' is not a quantity that is always positive.
>
> :>Yes, it is. QOH cannot go below zero unless you have a logic error.
> :>You either have stock on the shelf, or you don't. It isn't like a bank account,
> :>where you can sign up for overdraft protection.
>
> True quantity on hand cannot go negative.
>
> Recorded QOH however can go negative if the received goods were not properly
> recorded or not recorded in a timely way.
The whole point of having control systems is to ensure
that transactions are accurately recorded in a timely fashion.
QOH cannot go below zero unless you have a logic error.
Any "control system" that allows material release for shipment
under the conditions you mentioned has serious logic errors.
Binyamin Dissen
:>Binyamin Dissen <post...@dissensoftware.com> wrote in message news:qovusv8nt1e817fkg...@4ax.com...
:>> On Thu, 04 Dec 2003 18:18:23 GMT "Hugh Candlin" <n...@spam.com> wrote:
:>> :>Richard <rip...@Azonic.co.nz> wrote in message news:217e491a.03120...@posting.google.com...
:>> :>> scom...@aol.com (S Comstock) wrote
:>> :>> > Richard writes ...
:>> :>> > >There are plenty of uses for numbers that can not be negative, or
:>> :>> > >would be invalid if they were negative. Prices, discount rates, even
:>> :>> > >quantities.
:>> :>> > Quantities _should_ be signed. The human reality is, inventory in stock might
:>> :>> > not match inventory as recorded in the computer record. At least if the value
:>> :>> > shows up as negative you have some indication of trouble. If the field were
:>> :>> > designed to not allow negative numbers, then you start getting results that are
:>> :>> > wierd but that _look_ OK.
:>> :>> 'Stock on hand' is not a quantity that is always positive.
:>> :>Yes, it is. QOH cannot go below zero unless you have a logic error.
:>> :>You either have stock on the shelf, or you don't. It isn't like a bank account,
:>> :>where you can sign up for overdraft protection.
:>> True quantity on hand cannot go negative.
:>> Recorded QOH however can go negative if the received goods were not properly
:>> recorded or not recorded in a timely way.
:>The whole point of having control systems is to ensure
^^^^^^
attempt
:> that transactions are accurately recorded in a timely fashion.
:>QOH cannot go below zero unless you have a logic error.
Or a procedure error.
:>Any "control system" that allows material release for shipment
:>under the conditions you mentioned has serious logic errors.
How would that apply to a store?
Goods are delivered, placed on the shelf and purchased before being recorded
in the ICS. The sales register immediately records the sales.
I guess one could argue that the store should not place them on the shelf
until the paperwork is done, but the store is in the business of making money
and turning over the inventory ASAP.
Hugh Candlin
Binyamin Dissen <post...@dissensoftware.com> wrote in message news:8cevsv4dam40s7ckp...@4ax.com...
Any control system worthy of the name will ensure that daily receipts
are posted before processing the daily sales transactions.
> :>Any "control system" that allows material release for shipment
> :>under the conditions you mentioned has serious logic errors.
>
> How would that apply to a store?
The environment doesn't matter. You either have an accurate control system,
or you do not.
>
> Goods are delivered, placed on the shelf and purchased before being recorded
> in the ICS. The sales register immediately records the sales.
>
> I guess one could argue that the store should not place them on the shelf
> until the paperwork is done, but the store is in the business of making money
> and turning over the inventory ASAP.
If the "system" decrements QOH into negative territory,
then it is badly designed and incompetently programmed.
Alistair Maclean
<how...@brazee.net> writes
No.
--
Alistair Maclean
From the UK tv series "The Kumars at No. 42":
Grandmother Kumar interviewing Patrick Stewart (Captain
Jean-Luc Picard of the Federation Starship Enterprise),
"Why aren't there any Indians in Star Trek?
Don't you need any IT support?"
Binyamin Dissen
:>Binyamin Dissen <post...@dissensoftware.com> wrote in message news:8cevsv4dam40s7ckp...@4ax.com...
:>> :>> :>> scom...@aol.com (S Comstock) wrote
:>> :>> :>> > Richard writes ...
:>> Or a procedure error.
Ah, the batch mentality.
:>> :>Any "control system" that allows material release for shipment
:>> :>under the conditions you mentioned has serious logic errors.
:>> How would that apply to a store?
:>The environment doesn't matter. You either have an accurate control system,
:>or you do not.
I fail to see a reason to stop selling just to get the paperwork in order,
except period inventory checks.
:>> Goods are delivered, placed on the shelf and purchased before being recorded
:>> in the ICS. The sales register immediately records the sales.
I wonder why you have difficulty understanding this concept.
:>> I guess one could argue that the store should not place them on the shelf
:>> until the paperwork is done, but the store is in the business of making money
:>> and turning over the inventory ASAP.
:>If the "system" decrements QOH into negative territory,
:>then it is badly designed and incompetently programmed.
False.
LX-i
> Judson,
>
> I have posted several responses to your messages here but they are
> apparently not being echoed in North America.
They're echoed, just a couple of days late... I've been seeing 2-3 day
old messages from you for a couple of days now. It's funny - I'll see
people's replies to your message before I see the message itself.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi...@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hugh Candlin
Binyamin Dissen <post...@dissensoftware.com> wrote in message news:43kvsvgoshg17vt2r...@4ax.com...
Nooooo. I said nothing about "how". I used the words "control system".
That does not automatically mean "computer system" or "computer processing".
>
> :>> :>Any "control system" that allows material release for shipment
> :>> :>under the conditions you mentioned has serious logic errors.
>
> :>> How would that apply to a store?
>
> :>The environment doesn't matter. You either have an accurate control system,
> :>or you do not.
>
> I fail to see a reason to stop selling just to get the paperwork in order,
> except period inventory checks.
Agreed, although I don't see where you mentioned the need for that (?).
>
> :>> Goods are delivered, placed on the shelf and purchased before being recorded
> :>> in the ICS. The sales register immediately records the sales.
>
> I wonder why you have difficulty understanding this concept.
The concept is basic. No difficulty is involved, except in your mind.
>
> :>> I guess one could argue that the store should not place them on the shelf
> :>> until the paperwork is done, but the store is in the business of making money
> :>> and turning over the inventory ASAP.
>
> :>If the "system" decrements QOH into negative territory,
> :>then it is badly designed and incompetently programmed.
>
> False.
I (obviously) disagree. QOH is a well-defined concept.
It cannot be negative.
Peter Lacey
> "JerryMouse" <nos...@bisusa.com> wrote:
> >
> > Presumably, IBM is (was) working with the quaint concept that when you use a
> > number you intend to do arithmetic with it.
>
> How does that change the fact that adding a 'sign' that is permanently fixed
> to a numeric field is redundant? Is it so hard to accept that an unsigned
> numeric field is implicitly positive if used in math? Are computer designers
> so obtuse they can't design hardware that does arithmetic without actually
> 'seeing' an explicit sign? If so, only IBM engineers seem to be so impaired.
> When you were in school did they teach that you MUST write '+' beside a
> positive number or you could not possibly do arithmetic on it? :-)
What earthly difference does it make? You DON'T have to write a sign!
>
>
>
> You would not use a numeric field to store those, so 'sign' is irrelevant.
> That doesn't affect other 'identifying' numeric fields like employee numbers,
> part numbers or purely numeric G/L account numbers. There have always
> been numeric items that can never be negative or that do not represent scalar
> values. All of us have worked on computer systems with lots of fields that
> were numeric but could never be negative. Why in the world anyone would
> think it necessary to append a fixed 'sign' to each of these is beyond me. Any
> 'sign' that is permanently fixed is redundant. How can that not be blindingly
> obvious to everyone? Are your minds so brainwashed with the IBM mantra
> that you cannot think outside that frame of reference? Really now, I know
> you folks are far to smart to be confused by this! Admit it, you're just
> kidding us, right? :-)
Assuming you're not kidding us -- presumably the people who first thought about
this decided that it was less complicated to have numeric fields implemented in the
hardware with the sign position than to have two kinds of "numeric" fields, one
with, one without a sign. And very probably nobody since has thought it worth while
debating (yourself excluded, of course). How can you get so worked up over 4
(EBCDIC) bits?
I don't usually agree that the majority must be always right - but this has been in
existence so long that surely by now a compelling argument for dropping the sign
position would have emerged by now if there was one.
PL.
Richard
> > 'Stock on hand' is not a quantity that is always positive.
>
> Yes, it is. QOH cannot go below zero unless you have a logic error.
>
> You either have stock on the shelf, or you don't.
The computer system doesn't work by counting the stock items on the
shelf, it works by reading the number in a computer file.
There are several reasons why the computer can record a negative for
that number, some of which are not 'logic errors'.
It may be that some systems will _enforce_ the QOH to always be
positive, and will not let, say, an order to be entered if this would
exceed the QOH. If, however, this is only because the stock receival
procedure is held up for some trivial reason then the users will be
really pissed off at such an inflexible and authoritarian system, not
to say stupid.
The golden rule of systems (IMHO) is that regardless of what _should_
happen, it is only a tool, and it shouldn't get in the way of running
the business.
> QOH is not the same as [Quantity-on-hand less Inventory Demand],
> which can be a negative value.
That's another one.
Hugh Candlin
Richard <rip...@Azonic.co.nz> wrote in message news:217e491a.03120...@posting.google.com...
> "Hugh Candlin" <n...@spam.com> wrote
>
> > Yes, it is. QOH cannot go below zero unless you have a logic error.
> >
> > You either have stock on the shelf, or you don't.
>
> The computer system doesn't work by counting the stock items on the
> shelf,
I understand that. That is a function of cycle count.
> it works by reading the number in a computer file.
That's a very simplistic description, but I won't argue the toss.
>
> There are several reasons why the computer can record a negative for
> that number, some of which are not 'logic errors'.
They are ALL logic errors. You either have something, or you don't.
What does negative stock on the shelf look like?
That concept is nothing but trouble if it is allowed to occur in a "system".
> It may be that some systems will _enforce_ the QOH to always be
> positive,
No maybe. Mine does. Any that do not are wrong.
>
> and will not let, say, an order to be entered if this would
> exceed the QOH.
There is nothing whatsoever incorrect or improper
about allowing sales orders to be entered without
stock on hand to cover those orders. That simply
triggers a make-or-buy decision, which in turn
triggers a shop ticket or a purchase order to a supplier.
> If, however, this is only because the stock receival
> procedure is held up for some trivial reason then the users will be
> really pissed off at such an inflexible and authoritarian system, not
> to say stupid.
The same problem exists when the computer system or network goes down.
If the system does not incorporate workaround procedures,
then it isn't a system.
> The golden rule of systems (IMHO) is that regardless of what _should_
> happen, it is only a tool, and it shouldn't get in the way of running
> the business.
What I said, only expressed differently, but we agree here.
>
> > QOH is not the same as [Quantity-on-hand less Inventory Demand],
> > which can be a negative value.
>
> That's another one.
Another what?
Binyamin Dissen
:>Binyamin Dissen <post...@dissensoftware.com> wrote in message news:43kvsvgoshg17vt2r...@4ax.com...
:>> :>> :>> :>> scom...@aol.com (S Comstock) wrote
:>> :>> :>> :>> > Richard writes ...
:>> :>> Or a procedure error.
:>> Ah, the batch mentality.
In most stores the check-out (purchase) system has a scanner and is easy to
directly interface to the ICS.
The deliveries, on the other hand, are not.
You suggested that the sales data not be recorded until the deliveries are
recorded.
Certainly sounds like batch mentality.
:>> :>> :>Any "control system" that allows material release for shipment
:>> :>> :>under the conditions you mentioned has serious logic errors.
:>> :>> How would that apply to a store?
:>> :>The environment doesn't matter. You either have an accurate control system,
:>> :>or you do not.
:>> I fail to see a reason to stop selling just to get the paperwork in order,
:>> except period inventory checks.
:>Agreed, although I don't see where you mentioned the need for that (?).
You did.
"Any control system worthy of the name will ensure that daily receipts are
posted before processing the daily sales transactions."
:>> :>> Goods are delivered, placed on the shelf and purchased before being recorded
:>> :>> in the ICS. The sales register immediately records the sales.
:>> I wonder why you have difficulty understanding this concept.
:>The concept is basic. No difficulty is involved, except in your mind.
Snicker.
:>> :>> I guess one could argue that the store should not place them on the shelf
:>> :>> until the paperwork is done, but the store is in the business of making money
:>> :>> and turning over the inventory ASAP.
:>> :>If the "system" decrements QOH into negative territory,
:>> :>then it is badly designed and incompetently programmed.
:>> False.
:>I (obviously) disagree. QOH is a well-defined concept.
:>It cannot be negative.
To repeat:
True quantity on hand cannot go negative.
Recorded QOH however can go negative if the received goods were not properly
recorded or not recorded in a timely way.
--
Chuck Stevens
"Peter Lacey" <la...@mb.sympatico.ca> wrote in message
news:3FD00183...@mb.sympatico.ca...
> I don't usually agree that the majority must be always right - but this
has been in
> existence so long that surely by now a compelling argument for dropping
the sign
> position would have emerged by now if there was one.
The argument was compelling enough for a great many implementations to do
so. A table of sixty thousand one-digit unsigned packed-decimal items
occupies thirty thousand eight-bit bytes on a Unisys MCP system, and has
since the introduction of the 8-bit representation on that architecture on
the Burroughs Large System. Why is the counter-argument -- that the
packed-decimal representation of these items should occupy the same space as
a display representation of the same items -- compelling?
-Chuck Stevens
Richard
> > There are several reasons why the computer can record a negative for
> > that number, some of which are not 'logic errors'.
>
> They are ALL logic errors. You either have something, or you don't.
There may be a stock on the shelf that is not in the computer system
but that is not necessarily a _LOGIC_ error. It may be a keying
error, or a timing issue or an identification error, or any number of
other things.
The reverese of having no stock on the shelf but the computer showing
a number may also not be a _logic_ error, it may be theft of breakages
or simply put on the wrong shelf.
> No maybe. Mine does. Any that do not are wrong.
'Wrong' in what way ? Given that you know nothing about those other
systems, who are you to say that they are _wrong_.
They are only numbers, they represent particular states.
> > and will not let, say, an order to be entered if this would
> > exceed the QOH.
>
> There is nothing whatsoever incorrect or improper
> about allowing sales orders to be entered without
> stock on hand to cover those orders.
That depends entirely on the system that the business chooses to use.
> That simply
> triggers a make-or-buy decision, which in turn
> triggers a shop ticket or a purchase order to a supplier.
That may well be an excellent scheme for those businesses. Others
wish to run their businesses differently. For example my systems
generally warn the operator and allow the order quantity to be split
between available and back ordered, but the operator has the ability
to change the suggested quantities if the stock is _actually_
available and, for example, waiting to be processed in the receivals
area.
Triggering a PO is not a good idea, but then being at the end of the
earth here there may be lead times of months. This means there may
already be a shipment on its way. The business can choose to have the
whole sales order back ordered so it can be shipped at one time when
all stock available, or it can put the (free) stock into negative and
forward date it so it is not picked until the current shipment is
unpacked.
These are _different_ not wrong, and may be applicable to different
sized businesses.
> The same problem exists when the computer system or network goes down.
> If the system does not incorporate workaround procedures,
> then it isn't a system.
Exactly. The 'workaround' is to allow the (free) stock to go
negative.
> > That's another one.
>
> Another what?
Another quantity.
Judson McClendon
>
> "Judson McClendon" <ju...@sunvaley0.com> wrote:
> > Have you ever wondered why the original IBM 360 series was designed
> > to always require a sign in the first place?
>
> It wasn't. The original System 360, designed by Gene Amdahl, had no packed
> decimal. It was a pure binary machine, intended for (mainly) scientific
> applications. It utilised up to 64 bit (doubleword) binary, or floating
> point, or external decimal (which was converted to binary for calculations).
Peter, I am looking at a book titled "Logical Programming with System/360"
by Don H. Stabley, copyright 1970, John Wiley publisher. On page 60, is a
paragraph with the heading "2. Packed Decimal Data", and on the opposite
page (61) is a chart showing how various packed decimal values would be
stored, dutifully showing the (IBM required) sign nibble. How can you say
that the System/360 did not require a sign on packed decimal fields? We are
discussing packed decimal fields, no? Any packed decimal field on an IBM
System/360 or descendant requires a sign nibble. That's what I said, and it's
true.
> > Perhaps to sell more memory?
>
> Nope. Not at all. Memory (being hand made) was certainly expensive but one
> of the reasons for implementing packed in the first place was to SAVE
> memory.
Saving memory with packed decimal, yes. Saving memory by adding a
redundant mandatory sign to 'unsigned' fields, no. :-)
Don't reject that idea so casually. When it comes to using every possible
angle to sell more hardware, IBM was second to none in those days. Bill
Gates probably learned much of what he knows about that from watching
IBM. Gates did say he wanted to be "the IBM of software," remember?
LX-i
>>There are several reasons why the computer can record a negative for
>>that number, some of which are not 'logic errors'.
>
>
> They are ALL logic errors. You either have something, or you don't.
> What does negative stock on the shelf look like?
> That concept is nothing but trouble if it is allowed to occur in a "system".
I hate to get into this (and I should have learned my lesson by now),
but let's play...
I run Toys-R-Us. We have a pre-sale on Lion King Special Edition DVDs.
We sell 237 copies of these before the shipment even leaves for our
store. When the shipment arrives, my stock people in the back unload
the truck and pass the bill of lading on to the warehouse clerk, who
keys a receipt of 1,000, which adds 1,000 to our QOH of this item. Our
QOH is now 763, some of which will be pulled from the back and put out
on the shelf.
How did this happen? Each of these pre-sold copies decremented our QOH
by 1. Before the inventory arrived in the store, we had -237. Enter
the inventory - we now have 763 ready to sell.
Your system wouldn't support this?
Hugh Candlin
LX-i <lxi...@netscape.net> wrote in message news:vt28hgc...@corp.supernews.com...
> Hugh Candlin wrote:
> >>There are several reasons why the computer can record a negative for
> >>that number, some of which are not 'logic errors'.
> >
> > They are ALL logic errors. You either have something, or you don't.
> > What does negative stock on the shelf look like?
> > That concept is nothing but trouble if it is allowed to occur in a "system".
>
> I hate to get into this (and I should have learned my lesson by now),
> but let's play...
I make my living making sure that Inventory, Sales Orders, Inventory Demand,
Inventory Cost, Bill of Materials, Shop Tickets, Stock Reservation. Warehouse
Locator, Warehouse Allocation and numerous other databases are in sync.
I do not in any shape, manner or form see it as play, although I do enjoy my work.
>
> I run Toys-R-Us. We have a pre-sale on Lion King Special Edition DVDs.
A pre-sale. I understand.
> We sell
Stop here. Why are you treating 2 totally different procedures the same?
A pre-sale is not a sale.
You cannot ship a pre-sale, nor can you process it as a normal sales order.
There is a clue/hint there.
> 237 copies of these before the shipment even leaves for our store.
No. You have an encumbrance against future receipts of Inventory,
which may never arrive due to any number of factors.
A huge difference in business philosophy and accounting procedure.
You are financially booking sales of product that you do not own.
People go to jail for that.
I won't even ask how you provide pre-sale reports to management.
> When the shipment arrives, my stock people in the back unload
> the truck and pass the bill of lading on to the warehouse clerk, who
> keys a receipt of 1,000, which adds 1,000 to our QOH of this item. Our
> QOH is now 763, some of which will be pulled from the back and put out
> on the shelf.
>
> How did this happen? Each of these pre-sold copies decremented our QOH
> by 1.
A terrible design. I wish you well. Particularly as you find yourself unable to detect
actual problems by running a scan to ensure the absence of negative QOH,
although that is a trivial matter in the larger scheme.
Russell Styles
"Hugh Candlin" <n...@spam.com> wrote in message
news:maaAb.155950$Ec1.6...@bgtnsc05-news.ops.worldnet.att.net...
I don't see the problem. Those 237 DVD's are NOT sales. They
(hopefully)
do not effect the sales totals at all until the customer buys them. Call
them
pre-sales, call them something else. Bottom line, these 237 customers
are at the front of the line, should that particular product turn out to be
hot.
Now what you do call them, and what you tell upper management
is another question.
I suppose that you could take the customer's money at time of order.
I am really not competent to comment on the legal twists of that method.
I was assuming that no money changes hands until the merchandise changes
hands.
Hugh Candlin
Russell Styles <rws...@comcast.net> wrote in message news:dpGdnf9jX4d...@comcast.com...
Neither do I. I was, however, asked to comment on someone elses procedure.
> Those 237 DVD's are NOT sales.
That is true. They are open Sales Orders. They are not Sales.
You have not yet created a shipper and/or an Invoice.
> They
> (hopefully)
> do not effect the sales totals at all until the customer buys them.
That is what is being disputed. I stated that you cannot sell what you haven't got,
nor decrement Stock-on-Hand (QOH) that isn't on hand. Others disagree.
> Call them
> pre-sales, call them something else. Bottom line, these 237 customers
> are at the front of the line, should that particular product turn out to be
> hot.
Inventory Demand is what I call it, prioritized by Booking Date/ime Stamp.
> Now what you do call them, and what you tell upper management
> is another question.
If there is a question about that, then you do not have a control system.
You have a kludge of modules purporting to be a system.
> I suppose that you could take the customer's money at time of order.
Pre-payment processing would be defined as a requirement in the FSD
and incorporated appropriately, but that isn't the issue.
> I am really not competent to comment on the legal twists of that method.
> I was assuming that no money changes hands until the merchandise changes
> hands.
Money isn't the issue either, not is money changing hands a pre-requisite
to a financial booking transaction taking place.
Donald Tees
That is the siliest thing I have heard in years. People go to jail for
using a sign bit on an inventory control system? Perhaps you could
provide a reference, but I doubt it.
If you changed the above scenario to two different parameters, one
called stock-on-hand, and one called back-orders, plus a flag to keep
them straight, the math is exactly the same. However the code is more
complex, and more error prone.
In my opinion, there have been far more screw ups over the years due to
programmers demanding code based on their philosopies/egos taking
precidence over reality than any other single factor. I'll stick to
making the system work, thank you.
Harley
| newsgroup sponsor wrote:
| > Received a download file from an MVS system. Have a field that
| > appears to be packed decimal, but with no sign nibble. I understand
| > that this is a valid MVS data type, but I can't figure out what COBOL
| > data type would produce this field.
| >
| > Can anyone suggest?
| >
| > thanks ....
|
This is NOT a good idea.
Could be manipulation.
You can get one extra digit, by shifting everything right.
You take the number, multiply by 10.
Drop the trailing 0, and sign on the output.
i.e.
x'0123456F'
x'1234560F'
output:
x'123456'
SkippyPB
<ju...@sunvaley0.com> enlightened us:
>"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>
>> "Judson McClendon" <ju...@sunvaley0.com> wrote:
>> > Have you ever wondered why the original IBM 360 series was designed
>> > to always require a sign in the first place?
>>
>> It wasn't. The original System 360, designed by Gene Amdahl, had no packed
>> decimal. It was a pure binary machine, intended for (mainly) scientific
>> applications. It utilised up to 64 bit (doubleword) binary, or floating
>> point, or external decimal (which was converted to binary for calculations).
>
>Peter, I am looking at a book titled "Logical Programming with System/360"
>by Don H. Stabley, copyright 1970, John Wiley publisher. On page 60, is a
>paragraph with the heading "2. Packed Decimal Data", and on the opposite
>page (61) is a chart showing how various packed decimal values would be
>stored, dutifully showing the (IBM required) sign nibble. How can you say
>that the System/360 did not require a sign on packed decimal fields? We are
>discussing packed decimal fields, no? Any packed decimal field on an IBM
>System/360 or descendant requires a sign nibble. That's what I said, and it's
>true.
>
Let's clarify here. IBM required the sign nibble on a Packed Decimal
field if you wanted to perform arithmetic operations on it or move it
to an unpacked field. However, you could certainly store packed
decimal numbers on disk or tape without the sign nibble. I wrote many
an Assembler conversion program for some of the old banking systems
(including IBM's own PAL package) that stored data in this way. When
converting the data, we had to shift the data a half byte and insert a
sign so that the data could be used in Cobol in a Comp-3 data field.
>> > Perhaps to sell more memory?
>>
>> Nope. Not at all. Memory (being hand made) was certainly expensive but one
>> of the reasons for implementing packed in the first place was to SAVE
>> memory.
>
>Saving memory with packed decimal, yes. Saving memory by adding a
>redundant mandatory sign to 'unsigned' fields, no. :-)
>
>Don't reject that idea so casually. When it comes to using every possible
>angle to sell more hardware, IBM was second to none in those days. Bill
>Gates probably learned much of what he knows about that from watching
>IBM. Gates did say he wanted to be "the IBM of software," remember?
Regards,
////
(o o)
-oOO--(_)--OOo-
Real Tombstone Epitaphs:
In a Thurmont, Maryland, cemetery:
Here lies an Atheist
All dressed up And no place to go.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
Hugh Candlin
Donald Tees <donal...@nospam.sympatico.ca> wrote in message news:GdkAb.16068$yd.25...@news20.bellglobal.com...
They do? First time I have heard of that.
Perhaps you could provide a reference?
> Perhaps you could provide a reference, but I doubt it.
It is your claim. You provide the reference.
>
> If you changed the above scenario to two different parameters, one
> called stock-on-hand, and one called back-orders, plus a flag to keep
> them straight, the math is exactly the same. However the code is more
> complex, and more error prone.
Also a very poorly thought out methodology that I would not dream of using.
>
> In my opinion, there have been far more screw ups over the years due to
> programmers demanding code based on their philosopies/egos taking
> precidence over reality than any other single factor. I'll stick to
> making the system work, thank you.
That's what I said. Do try to keep up.
Richard
> Saving memory with packed decimal, yes. Saving memory by adding a
> redundant mandatory sign to 'unsigned' fields, no. :-)
>
> Don't reject that idea so casually. When it comes to using every possible
> angle to sell more hardware, IBM was second to none in those days.
There was proably _less_ hardware used because the design could be
simplified by not having to have options for signed and unsigned.
In any case leaving the sign nibble off only saves memory half the
time as the number is byte aligned.
You are also wrong that IBM wanted to sell more hardware, what it
wanted to do was get more money. If it could do this with _less_
hardware then it would. Leaving off the hardware to support two types
of packed decimal achieved this.
Judson McClendon
you saying that there is a way on IBM mainframes to declare a COBOL
field PIC 9999 as pure binary coded decimal so that it will be stored
in two bytes with no sign nibble (no assembly!)? If the answer is 'yes'
then I concede your point. If the answer is 'no' then you should concede
my point. Fair enough? :-)
--
Judson McClendon ju...@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Richard
> Could you tell why a subscript is an integer (i.e that could be negative)???
In some languages subscripts can be negative.
> I would suggest for clarity of any discourse to use the term NATURAL for
> whatever is zero or positive and INTEGER for a negative/positive domain of
> value....(as specified more or less in elementatry mathematic)
Modula2 uses CARDINAL, but in fact indexes should be ORDINAL.
Judson McClendon
> Judson McClendon wrote:
> > "JerryMouse" <nos...@bisusa.com> wrote:
> > >
> > > Presumably, IBM is (was) working with the quaint concept that when you use a
> > > number you intend to do arithmetic with it.
> >
> > How does that change the fact that adding a 'sign' that is permanently fixed
> > to a numeric field is redundant? Is it so hard to accept that an unsigned
> > numeric field is implicitly positive if used in math? Are computer designers
> > so obtuse they can't design hardware that does arithmetic without actually
> > 'seeing' an explicit sign? If so, only IBM engineers seem to be so impaired.
> > When you were in school did they teach that you MUST write '+' beside a
> > positive number or you could not possibly do arithmetic on it? :-)
>
> What earthly difference does it make? You DON'T have to write a sign!
Agreed. Then the computer need not store a sign for an unsigned numeric
field, for precisely the same reason. :-)
> > You would not use a numeric field to store those, so 'sign' is irrelevant.
> > That doesn't affect other 'identifying' numeric fields like employee numbers,
> > part numbers or purely numeric G/L account numbers. There have always
> > been numeric items that can never be negative or that do not represent scalar
> > values. All of us have worked on computer systems with lots of fields that
> > were numeric but could never be negative. Why in the world anyone would
> > think it necessary to append a fixed 'sign' to each of these is beyond me. Any
> > 'sign' that is permanently fixed is redundant. How can that not be blindingly
> > obvious to everyone? Are your minds so brainwashed with the IBM mantra
> > that you cannot think outside that frame of reference? Really now, I know
> > you folks are far to smart to be confused by this! Admit it, you're just
> > kidding us, right? :-)
>
> Assuming you're not kidding us -- presumably the people who first thought about
> this decided that it was less complicated to have numeric fields implemented in the
> hardware with the sign position than to have two kinds of "numeric" fields, one
> with, one without a sign. And very probably nobody since has thought it worth while
> debating (yourself excluded, of course). How can you get so worked up over 4
> (EBCDIC) bits?
Stupid waste always bothers me. And people defending stupid waste as if
it were not stupid waste also bothers me. Sorry. :-)
> I don't usually agree that the majority must be always right - but this has been in
> existence so long that surely by now a compelling argument for dropping the sign
> position would have emerged by now if there was one.
Compelling meaning change the minds of all the IBM indoctrinated people
out there? No, I obviously shouldn't expect that. :-)
Judson McClendon
> Richard <rip...@Azonic.co.nz> wrote:
> >
> > 'Stock on hand' is not a quantity that is always positive.
>
> Yes, it is. QOH cannot go below zero unless you have a logic error.
> You either have stock on the shelf, or you don't. It isn't like a bank account,
> where you can sign up for overdraft protection.
>
> which can be a negative value.
Technically, you are correct. However, business systems are rarely so
clean. You must allow for human errors in the system, such as failing
to input a received shipment. If that is done, then when you ship those
items out, you could easily run a negative QOH, or lose the amount of
inventory involved altogether (if you don't keep the negative quantity
you don't know how short you really are). How 'tight' you can make
such systems depends on factors like how the organization functions
and just how strict the people who run the show want the computer to
be. Some users would insist you should never ship items if the QOH
does go negative, but others would say "Why hold up an important
shipment to a customer because we screwed up on data entry? We'll
deal with that later."
Binyamin Dissen
wrote:
:>"Hugh Candlin" <n...@spam.com> wrote:
:>> Richard <rip...@Azonic.co.nz> wrote:
:>> > 'Stock on hand' is not a quantity that is always positive.
:>> Yes, it is. QOH cannot go below zero unless you have a logic error.
:>> You either have stock on the shelf, or you don't. It isn't like a bank account,
:>> where you can sign up for overdraft protection.
:>> QOH is not the same as [Quantity-on-hand less Inventory Demand],
:>> which can be a negative value.
:>Technically, you are correct. However, business systems are rarely so
:>clean. You must allow for human errors in the system, such as failing
:>to input a received shipment. If that is done, then when you ship those
:>items out, you could easily run a negative QOH, or lose the amount of
:>inventory involved altogether (if you don't keep the negative quantity
:>you don't know how short you really are). How 'tight' you can make
:>such systems depends on factors like how the organization functions
:>and just how strict the people who run the show want the computer to
:>be. Some users would insist you should never ship items if the QOH
:>does go negative, but others would say "Why hold up an important
:>shipment to a customer because we screwed up on data entry? We'll
:>deal with that later."
That is the major point that some have difficulty comprehending.
The point of the business is to sell its product, not to make sure that the
inventory figures are correct at all times.
Software that refuses to allow sales because it thinks the numbers are out of
wack is bad software.
The software should warn, but must allow an override.
Peter E.C. Dashwood
There's nothing I can do about it without changing ISPs (and that's a bit
drastic...). It may just be a temporary thing with the Network becoming
loaded with Xmas mail and such... or it might just be a change in
infrastructure to the NZ backbone.
If it is no better by January, I'll explore some other options.
Pete.
"LX-i" <lxi...@netscape.net> wrote in message
news:vsvk8j3...@corp.supernews.com...
Judson McClendon
> > that number, some of which are not 'logic errors'.
>
> They are ALL logic errors. You either have something, or you don't.
> What does negative stock on the shelf look like?
> That concept is nothing but trouble if it is allowed to occur in a "system".
Hugh, I don't mean to offend you, but if you had spent a little time in
the consulting business dealing with actual customers, the ones writing
your check, you would never espouse such an inflexible attitude. As
Richard has alluded, it would get your butt kicked out the door fast
enough to make your head spin if you tell the owner of a company that
they CANNOT sell an item until they have entered the item received
into the computer. Just because your experience is limited in that you
have not encountered this does not mean that it doesn't work that way.
Believe me, your position is actually humerous to those of us who
have BTDT many, many times. Business is simply not as clean as we
might like to be sometimes. This is not 'logic error', it is dealing with
reality that is often messy. Remember, the tail does not wag the dog. :-)
> > It may be that some systems will _enforce_ the QOH to always be
> > positive,
>
> No maybe. Mine does. Any that do not are wrong.
No, you are the one who is wrong. Your system may be doing exactly
what it should be doing in your situation. But your situation does not
encompass every conceivable inventory control situation. Believe me,
it doesn't. Try to understand that.
> > and will not let, say, an order to be entered if this would
> > exceed the QOH.
>
> There is nothing whatsoever incorrect or improper
> about allowing sales orders to be entered without
> stock on hand to cover those orders. That simply
> triggers a make-or-buy decision, which in turn
> triggers a shop ticket or a purchase order to a supplier.
Right, the customer walks in, sees a $10,000 item on the shelf, says
"I want to buy that" and holds out the cash. The owner then goes to
his computer to find out that his idiot brother-in-law entered the
item incorrectly and the inventory does not show the item in stock.
Now, you are telling us you really think the owner of that store is
going to tell that customer "Well, I know that item is setting there,
but my computer does not show it in stock. You will just have to
wait until I can fire off an order to get another one you can buy."
Right. Hugh, if you think any store owner on the planet is really
going to do that, you're nuts! ;-)
Peter E.C. Dashwood
> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
> >
> > "Judson McClendon" <ju...@sunvaley0.com> wrote:
> > > Have you ever wondered why the original IBM 360 series was designed
> > > to always require a sign in the first place?
> >
> > It wasn't. The original System 360, designed by Gene Amdahl, had no
packed
> > decimal. It was a pure binary machine, intended for (mainly) scientific
> > applications. It utilised up to 64 bit (doubleword) binary, or floating
> > point, or external decimal (which was converted to binary for
calculations).
>
> Peter, I am looking at a book titled "Logical Programming with System/360"
> by Don H. Stabley, copyright 1970, John Wiley publisher. On page 60, is a
> paragraph with the heading "2. Packed Decimal Data", and on the opposite
> page (61) is a chart showing how various packed decimal values would be
> stored, dutifully showing the (IBM required) sign nibble.
Thank you for quoting your reference. I have no quibble with that particular
"Authority", but I certainly take issue with the way you have interpreted
it.
> How can you say
> that the System/360 did not require a sign on packed decimal fields?
I didn't say that. (But I'm going to now <G>...see below).
(Although in the early days using BAL (System 360 Assembler), we routinely
packed data without storing a sign in it... It is an ARITHMETIC requirement,
NOT a storage requirement. It certainly requires a sign for COBOL.)
I said S360 users have a CHOICE of arithmetic formats, and at least one of
these supports unsigned decimal fields, even for arithmetic.
YOU said the S360 "was designed to always require a sign" (you can see the
quote above; I'm not making it up...<G>) and I corrected you on this.
> We are
> discussing packed decimal fields, no?
Now, that is a fair point, given the topic. However, like the majority of
posts in CLC, this one drifts on and off topic.
I would agree with you that we are "discussing packed fields" at least some
of the time. In my own posts I was very clear about what applied to packed
and what didn't, but I did not always stay exactly on topic.
> Any packed decimal field on an IBM
> System/360 or descendant requires a sign nibble. That's what I said, and
it's
> true.
>
No, it isn't.
Sadly, restating it confidently and emphatically just makes you more
emphatically wrong.
A sign nibble is required for ARITHMETIC fields (fields which we intend to
use in calculation). There is NO intrinsic requirement for packed fields to
use the last nibble as a sign. You can PACK anything; only when you try to
do arithmetic on it will you get a S0c7, if it doesn't contain a valid
arithmetic sign. (As many Assembler programmers found to our cost...and many
COBOL programmers have found to their cost, right up to the present time,
when they move spaces to a group level containing packed fields, thereby
"packing a blank". Note the system does NOT crash on the MOVE; it crashes as
soon as you use one of the packed fields for ARITHMETIC.)
> > > Perhaps to sell more memory?
> >
> > Nope. Not at all. Memory (being hand made) was certainly expensive but
one
> > of the reasons for implementing packed in the first place was to SAVE
> > memory.
>
> Saving memory with packed decimal, yes. Saving memory by adding a
> redundant mandatory sign to 'unsigned' fields, no. :-)
>
And you have no problem reconciling these two conflicting ideas in your
mind? (It must be Hell in there...<G>)
> Don't reject that idea so casually.
When an idea is blatantly stupid I do tend to dismiss it.
Do you have any other evidence for your axiomatically unsound, unsupported,
assertion, that would warrant my expending brain cells on re-evaluating it?
I think not.
> When it comes to using every possible
> angle to sell more hardware, IBM was second to none in those days.
That is certainly true, but they never descended to the obviously absurd.
> Bill
> Gates probably learned much of what he knows about that from watching
> IBM. Gates did say he wanted to be "the IBM of software," remember?
Switching your losing argument to enlist the anti-Bill Gates camp cuts no
ice with me <G> .
(Either as a rhetorical device or as support for your case. What Bill Gates
did or did not say has as much relevance to this discussion as General
Relativity does to an archer fish contemplating a fly. (Figure that one out
for yourself...<G>))
Who's off-topic now <G>?
Pete.
Peter E.C. Dashwood
I read this after I formulated my response to Judson, but it endorses my own
position on this.
I think that because this is a COBOL forum, many people (in particular,
Judson) just aren't aware that Packed can be used in this way.
It is ironic that he has convinced himself that the sign is a ploy by IBM
to sell more memory <G>.
Pete.
"SkippyPB" <swie...@neo.rr.NOSPAM.com> wrote in message
news:nc14tv0c1g1r9u8cq...@4ax.com...
William M. Klein
I guess I am confused about exactly whether this is an argument about
terminology or history or what.
There SEEMS to be agreement that on S/360 and subsequent IBM "mainframe"
machines, one must have a "valid" sign-nibble in a packed-decimal field in order
to do arithmetic on it.
Furthermore, I think we all agree that all such machines support UNSIGNED
"zoned-decimal" numeric items (that one can do arithmetic on).
The question (seems to me) to come down to whether you can "pack" an unsigned
numeric value into a "valid" packed field that you will NOT be doing arithmetic
on.
Here I think the "terminology" problem arises. Yes, you certainly can put the
"bit-patterns" representing the digits from 0-9 in each nibble of a field and
that is a "valid" storage of something in S/360 and following. HOWEVER, in
IBM's terminology this is NOT (and as far as I know, never has been) a "valid
packed field". For the most current definition, see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr002/8.1.2
which is the definition of "Packed Format" and which says (in part),
" In the packed format, each byte contains two decimal digits (D), except
for the rightmost byte, which contains a sign to the right of a decimal
digit."
which (seems to me) to indicate that if the last nibble isn't a sign, it isn't
in "packed format".
Concerning the "question" of whether you can "pack" data that does NOT include a
sign nibble in the penultimate nibble of a zoned decimal sending item,
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr002/7.5.98
implies (or I infer) that you may - but are "minimally" supported - as it says,
"The second operand is treated as having the zoned format. The numeric bits of
each byte are treated as a digit. The zone bits are ignored, except the zone
bits in the rightmost byte, which are treated as a sign."
It even addresses what I think started this conversation when it says,
"3. To remove the zone bits of all bytes of a field, including the rightmost
byte, both operands should be extended on the right with a dummy byte, which
subsequently should be ignored in the result field."
So you probably (and I suspect some mainframe assembler programmers DO) "pack"
fields where the sending field's sign-nibble is not A-F. As Pete and Steve
indicated, you will be in "trouble" if you then try to use this in arithmetic -
furthermore, you can, however, even use the UNPACK instruction - as
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr002/7.5.141
says,
"The sign and digits are not checked for valid codes."
So if your sending field were X"ABCDE1" - when you unpack it you will get (I
think)
X"FAFBFCFD1E"
which must be useful <G> for something.
For further information on
"Decimal-Operand Data Exception"
(known and loved by IBM mainframe COBOL programmers as S0C7), see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr002/8.2.5
***
Does this put us all back talking about the same things????
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
news:3fd26...@news.athenanews.com...
Judson McClendon
>
> (Although in the early days using BAL (System 360 Assembler), we routinely
> packed data without storing a sign in it... It is an ARITHMETIC requirement,
> NOT a storage requirement. It certainly requires a sign for COBOL.)
I never intended to question that data could be packed like that in assembly,
or even cleverly written COBOL. What I have been trying to express is that
it is not supported as a data type by the hardware, and that you could not do
arithmetic using an unsigned packed decimal field without having a sign,
both of which are supported by all the non-IBM hardware I am currently
familiar with. Your post above seems to say you agree with me. :-)
Anyway, I think we've rode this horse to death. :-)