JUSTIFIED CENTER
LX-i
working-storage? Or maybe an intrinsic function? I dug through the
free 2002 standard document I have, and the only "Center" I found was in
Report Writer. Does anyone other than me think that this would be
handy? I know we have an application for it where I work.
Opinions always welcomed...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / Live from Montgomery, AL! ~
~ / \/ o ~
~ / /\ - | AIM: LXi0007 ~
~ _____ / \ | E-mail: DanielJS "at" Knology.net ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove NOSPAM to e-mail me...
JerryMouse
"LX-i" <DanielJ...@Knology.net> wrote in message
news:3EE24B8...@Knology.net...
> Is there any interest in this clause that can be used in
> working-storage? Or maybe an intrinsic function? I dug through the
> free 2002 standard document I have, and the only "Center" I found was in
> Report Writer. Does anyone other than me think that this would be
> handy? I know we have an application for it where I work.
There's probably more interest - especially from novices - in "Justified
Right."
But probably not a lot of interest inasmuch as most programmers already have
these in their 'toolkit,' having developed or copied them long ago.
Anon
LX-i
> "LX-i" <DanielJ...@Knology.net> wrote in message
> news:3EE24B8...@Knology.net...
>
>>Is there any interest in this clause that can be used in
>>working-storage? Or maybe an intrinsic function? I dug through the
>>free 2002 standard document I have, and the only "Center" I found was in
>>Report Writer. Does anyone other than me think that this would be
>>handy? I know we have an application for it where I work.
>
>
> There's probably more interest - especially from novices - in "Justified
> Right."
But "Justified Right" exists, whereas the one in the subject line does not.
> But probably not a lot of interest inasmuch as most programmers already have
> these in their 'toolkit,' having developed or copied them long ago.
I know there are ways to do it, but a clause would be the easiest... :)
Let the compiler do it!
JerryMouse
"LX-i" <DanielJ...@Knology.net> wrote in message
> JerryMouse wrote:
> > "LX-i" <DanielJ...@Knology.net> wrote in message
> > news:3EE24B8...@Knology.net...
> >
> >>Is there any interest in this clause that can be used in
> >>working-storage? Or maybe an intrinsic function? I dug through the
> >>free 2002 standard document I have, and the only "Center" I found was in
> >>Report Writer. Does anyone other than me think that this would be
> >>handy? I know we have an application for it where I work.
> >
> >
> > There's probably more interest - especially from novices - in "Justified
> > Right."
>
> But "Justified Right" exists, whereas the one in the subject line does
not.
But nobody uses justified right. Those who try to use it think it means
something else, spending inordinate amounts of time and effort trying to get
it to do something it wasn't designed to do.
LX-i
> "LX-i" <DanielJ...@Knology.net> wrote in message
>>But "Justified Right" exists, whereas the one in the subject line does
>>not.
>
> But nobody uses justified right. Those who try to use it think it means
> something else, spending inordinate amounts of time and effort trying to get
> it to do something it wasn't designed to do.
Ah well - I just wrote a little subprogram to do it. What the heck -
I'll post it. :) (Haven't compiled it yet, as they rebooted the
mainframe out from under me...)
=-=-=-=-=
Identification Division.
Program-ID. NFS-Center.
*>________________________________________________________________
*>
*> NFS-Center TEXT CENTERING SUBPROGRAM
*>
*> This subprogram will center input text based on the given
*> length of input, up to 132 characters.
*>
*> Author: SSgt Daniel J Summers
*> Date Written: June 2003
*> Security: Unclassified
*>________________________________________________________________
Data Division.
Working-Storage Section.
01 sHoldText Pic X(132).
01 iLeadingSpaces Pic 9(03).
01 iTrailingSpaces Pic 9(03).
01 iStrippedLength Pic 9(03).
*>________________________________________________________________
Linkage Section.
01 sInputText.
03 sInputTextElt Occurs 1 to 132 Times
Depending on iInputLength
Pic X(01).
01 iInputLength Pic 9(03).
*>________________________________________________________________
Procedure Division
Using sInputText iInputLength
. NFS-Center.
*> Initialize everything in case this has been called before
Move Zeroes to iLeadingSpaces iTrailingSpaces
iStrippedLength
Move Spaces to sHoldText
*> Get the leading and trailing spaces
Inspect sInputText
Tallying iLeadingSpaces for Leading Space
Inspect Function Reverse (sInputText)
Tallying iTrailingSpaces for Leading Space
*> Get the length of the actual text input
Compute iStrippedLength
= iInputLength - iLeadingSpaces - iTrailingSpaces
*> Figure out how many leading spaces should be on the output
Compute iLeadingSpaces
= (iInputLength - iStrippedLength) / 2
*> Center the input in the buffer
Move sInputText (iLeadingSpaces:iInputLength)
to sHoldText
Move Spaces to sInputText
Move sHoldText (1:iStrippedLength)
to sInputText (iLeadingSpaces:iStrippedLength)
Exit Program
*>________________________________________________________________
. End Program NFS-Center.
=-=-=-=-=
No warranty exists, express or implied... :)
LX-i
> Ah well - I just wrote a little subprogram to do it. What the heck -
> I'll post it. :) (Haven't compiled it yet, as they rebooted the
> mainframe out from under me...)
okay, before you all tell me that this doesn't work, let me swap out a
line...
replace
> *> Center the input in the buffer
> Move sInputText (iLeadingSpaces:iInputLength)
> to sHoldText
with
*> Center the input in the buffer
Move sInputText (iLeadingSpaces:iStrippedLength)
to sHoldText
and, of couse, still...
LX-i
> *> Figure out how many leading spaces should be on the output
> Compute iLeadingSpaces
> = (iInputLength - iStrippedLength) / 2
>
> *> Center the input in the buffer
> Move sInputText (iLeadingSpaces:iInputLength)
> to sHoldText
That won't work either... When will I learn....
(I need to move the input to the hold area, then recompute leading
spaces and move it back.)
Robert Wagner
>Is there any interest in this clause that can be used in
>working-storage? Or maybe an intrinsic function? I dug through the
>free 2002 standard document I have, and the only "Center" I found was in
>Report Writer. Does anyone other than me think that this would be
>handy? I know we have an application for it where I work.
The only things centered are page and column headings (on screen or paper).
They're static. You do 'em once when you write the program.
For page headers, I write the text and measure its length with the text editor,
subtracting first column - 1 from last. Then I put a filler in front for half
the difference between presentation width and string length. For example, say
the page width is 80:
01 page-headings.
05 line-1.
10 to-center pic x(21).
10 value 'D a i l y S c o r e R e p o r t' pic x(59).
For column headings, I first write the detail line, then copy it to the header
(one for one correspondence), delete data names, change all pics to x, define a
literal the full width of each field (-1 for separator), center the text inside
that literal. This makes it easier to insert and delete columns. For example:
01 detail-lines.
05 line-1.
10 credit-card-number pic x(17).
10 victim-status pic x(07)
10 amount-embezzled pic zzz,zzz,zzz-.
10 victim-name pic x(31).
01 header-lines.
05 line-3.
10 value ' social ' pic x(17).
10 value 'status' pic x(07).
10 value ' amount ' pic x(12).
10 value ' name of ' pic x(31).
05 line-4.
10 value ' ' pic x(17).
10 value ' ' pic x(07).
10 value ' taken ' pic x(12).
10 value ' mark ' pic x(31).
Warren Simmons
If so, perhaps a call to the funtion available in many editors would
simplify the process.
I've seen the same features on many programs, and don't think an author
would write one when
the feature and two others come with the OS>
Of course the assumption that there is an API available is not a good
assumption. Perhaps
the factory can create one on the fly.
Warren
Frederico Fonseca
wrote:
>
>"LX-i" <DanielJ...@Knology.net> wrote in message
>news:3EE26AD9...@Knology.net...
>> JerryMouse wrote:
>> > "LX-i" <DanielJ...@Knology.net> wrote in message
>> > news:3EE24B8...@Knology.net...
>> >
>> >>Is there any interest in this clause that can be used in
>> >>working-storage? Or maybe an intrinsic function? I dug through the
>> >>free 2002 standard document I have, and the only "Center" I found was in
>> >>Report Writer. Does anyone other than me think that this would be
>> >>handy? I know we have an application for it where I work.
>> >
>> >
>> > There's probably more interest - especially from novices - in "Justified
>> > Right."
>>
>> But "Justified Right" exists, whereas the one in the subject line does
>not.
>
>But nobody uses justified right. Those who try to use it think it means
>something else, spending inordinate amounts of time and effort trying to get
>it to do something it wasn't designed to do.
>
In addition to Daniel example here is one I had originaly working with
COBOL-74 (a minor change was done to it to have inline perform as
oposed to the original version that used "perform dummy").
This version will work with any compiler that supports inline perform,
even if it does not support the intrinsic functions as Daniel example
requires.
Required input.
CTR-VAR - Variable to work with
CTR-TAM - size of the destination variable
CTR-JUST - Possible values
spaces = get variable size
"D" - Justify right
"C" - Center text
"L" - Justify left
IDENTIFICATION DIVISION.
PROGRAM-ID. ROTCENTR.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 XE PIC 999.
01 XD PIC 999.
01 Y PIC 999.
01 Z PIC 999.
01 W1-DES.
05 W1-DES1 PIC X(256) VALUE SPACES.
05 W1-DES1R REDEFINES W1-DES1 OCCURS 256 PIC X.
01 W2-DES.
05 W2-DES1 PIC X(256) VALUE SPACES.
05 W2-DES1R REDEFINES W2-DES1 OCCURS 256 PIC X.
LINKAGE SECTION.
01 CTR-TAM PIC 999.
01 CTR-TAM1 PIC 999.
01 CTR-VAR PIC X(256).
01 CTR-JUST PIC X.
PROCEDURE DIVISION USING CTR-TAM
CTR-TAM1
CTR-VAR
CTR-JUST.
INIC.
IF CTR-VAR = SPACES OR CTR-TAM = 0 GO FIM-MESMO.
PERFORM CALC-TAM.
IF CTR-JUST = "D" PERFORM JUST-D.
IF CTR-JUST = "E" PERFORM JUST-E.
IF CTR-JUST = "C" PERFORM JUST-C.
MOVE W2-DES TO CTR-VAR.
FIM-MESMO.
EXIT PROGRAM.
CALC-TAM.
MOVE CTR-VAR TO W1-DES1.
PERFORM VARYING XD
FROM CTR-TAM BY -1
UNTIL XD < 1
OR W1-DES1R(XD) NOT = SPACES
END-PERFORM.
MOVE XD TO CTR-TAM1.
PERFORM VARYING XE
FROM 1 BY 1
UNTIL XE > CTR-TAM
OR W1-DES1R(XE) NOT = SPACES
END-PERFORM.
JUST-C.
COMPUTE Y = (CTR-TAM - XD) / 2 + 1 + (XE / 2).
PERFORM VARYING Z
FROM XE BY 1
UNTIL Z > XD
MOVE W1-DES1R(Z) TO W2-DES1R(Y)
ADD 1 TO Y
END-PERFORM.
JUST-D.
MOVE CTR-TAM TO Y.
PERFORM VARYING Z
FROM XD BY -1
UNTIL Z < XE
OR Z = 0
MOVE W1-DES1R(Z) TO W2-DES1R(Y)
SUBTRACT 1 FROM Y
END-PERFORM.
JUST-E.
MOVE 1 TO Y.
PERFORM VARYING Z
FROM XE BY 1
UNTIL Z > XD
MOVE W1-DES1R(Z) TO W2-DES1R(Y)
ADD 1 TO Y
END-PERFORM.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
Peter E.C. Dashwood
As I mentioned elsewhere I have a strong aversion to using
OCCURS...DEPENDING.
(A personal preference, but based on long and sometimes bitter
experience...)
In the Linkage section, particularly, this is a disaster just waiting to
happen.
I figured it isn't really fair to object to something and not show why it
isn't necessary. I have therefore taken your code and modified it.
This is not intended as a comment on the code you posted in any way other
than to remove ODO, and put in some very basic checks and improve
efficiency. I hate posting code here because it invariably starts religious
wars. On this occasion, I have little option.
If you compile this code it will run and return a correct result. I have
tested it as both a main and a called program.
Here is the code:
Identification Division.
Program-ID. NFS-Center.
*>________________________________________________________________
*>
*> NFS-Center TEXT CENTERING SUBPROGRAM
*>
*> This subprogram will center input text based on the given
*> length of input, up to 132 characters.
*>
*> Author: SSgt Daniel J Summers
*>
*> Modified by Pete Dashwood to remove ODO and improve efficiency.
*>
*> As the real length of the data is being passed, it is pointless
*> for the target text to have leading spaces.
*>
*> It is sufficient to simply pass (e.g.) "ABC DEF" and a length of 13.
*> We know (or can easily calculate) that the result requires 3
*> spaces leading and 3 spaces trailing...
*>
*> However, as this is an exercise, the code below detects leading
*> spaces and acts accordingly...
*>
*> Date Written: June 2003
*> Security: Unclassified
*>________________________________________________________________
Data Division.
Working-Storage Section.
01 sHoldText Pic X(132).
01 work-integers usage comp.
12 iLeadingSpaces Pic s9(03).
12 iLeadingInSpaces Pic s9(03).
12 iTrailingSpaces Pic s9(03).
12 iStrippedLength Pic s9(03).
*>________________________________________________________________
Linkage Section.
01 sInputText.
03 sInputTextElt pic x(132).
01 iInputLength Pic 9(03).
*>________________________________________________________________
Procedure Division
Using sInputText iInputLength
.
NFS Section.
do-the-biz.
*> Initialize everything in case this has been called before
Move Zeroes to iLeadingSpaces
iLeadingInSpaces iStrippedLength
move -132 to iTrailingSpaces
Move Spaces to sHoldText
*> Get the leading and trailing spaces
if sInputText (1:1) = space
Inspect sInputText
Tallying iLeadingInSpaces for Leading Space
else
move zero to iLeadingInSpaces
end-if
*> Trap all blank input string
if iLeadingInSpaces NOT < iInputLength
go to back-to-caller
end-if
Inspect Function Reverse (sInputText)
Tallying iTrailingSpaces for Leading Space
add iInputLength to iTrailingSpaces
*> Get the length of the actual text input
Compute iStrippedLength
= iInputLength - iLeadingInSpaces - iTrailingSpaces
*> Figure out how many leading spaces should be on the output
Compute iLeadingSpaces
= (iInputLength - iStrippedLength) / 2
*> Center the input in the buffer
Move sInputText (iLeadingInSpaces + 1:iStrippedLength)
to sHoldText (iLeadingSpaces + 1:)
Move sHoldText
to sInputText
.
back-to-caller.
Exit Program.
*>________________________________________________________________
LX-i
> Daniel,
>
> As I mentioned elsewhere I have a strong aversion to using
> OCCURS...DEPENDING.
>
> (A personal preference, but based on long and sometimes bitter
> experience...)
>
> In the Linkage section, particularly, this is a disaster just waiting to
> happen.
I must have missed this - what's the impending disaster with ODO?
> I figured it isn't really fair to object to something and not show why it
> isn't necessary. I have therefore taken your code and modified it.
Fine with me - it was sort of a brainstorm to begin with. I found 2
errors after I posted it, and looking at yours, I had a couple of other
ones. (i.e.,
Move sInputText (iLeadingSpaces + 1:iStrippedLength)
^^^^
> Here is the code:
Thanks! :)
JerryMouse
"LX-i" <DanielJ...@Knology.net>
> >
> > In the Linkage section, particularly, this is a disaster just waiting to
> > happen.
>
> I must have missed this - what's the impending disaster with ODO?
>
It's the obvious: a wrong value can hose the cat.
What's worse is that the runtime doesn't (usually/sometimes) check for a
wrong value. For example,
05 MYFIELD OCCURS 1 TO 100 DEPENDING ON MYLEN PIC X.
...
(implicitly moving 1,000,000 to MYLEN then...)
MOVE SPACE TO MYFIELD
makes one want to give up programming and open a pig farm.
Better:
05 MYFIELD PIC X(100)
(implicitly moving 1,000,000 to MYLEN then...)
MOVE SPACE TO MYFIELD(1:MYLEN)
at least contains the damage.
Experience teaches that ODO *CAN* have limited utility in a carefully
controlled environment.
Robert Wagner
>Is the program running on Windows?
>
>If so, perhaps a call to the funtion available in many editors would
>simplify the process.
My editor doesn't have a center function. I could write a macro to do it, in
COBOL.
>I've seen the same features on many programs, and don't think an author
>would write one when
>the feature and two others come with the OS>
What Windows API function centers text? TextOut can do it, but only in the
course of displaying text on the screen.
>Of course the assumption that there is an API available is not a good
>assumption. Perhaps
>the factory can create one on the fly.
What's the factory?
Richard
> (implicitly moving 1,000,000 to MYLEN then...)
>
> MOVE SPACE TO MYFIELD
>
> makes one want to give up programming and open a pig farm.
Or perhaps the choice is made for you by management ;-)
Peter E.C. Dashwood
"LX-i" <DanielJ...@Knology.net> wrote in message
> Peter E.C. Dashwood wrote:
> > Daniel,
> >
> > As I mentioned elsewhere I have a strong aversion to using
> > OCCURS...DEPENDING.
> >
> > (A personal preference, but based on long and sometimes bitter
> > experience...)
> >
> > In the Linkage section, particularly, this is a disaster just waiting to
> > happen.
>
> I must have missed this - what's the impending disaster with ODO?
>
Have a look at my response to your post in the "Is it possible to put any
character (0 - 255) in a PIC X"
thread
> > I figured it isn't really fair to object to something and not show why
it
> > isn't necessary. I have therefore taken your code and modified it.
>
> Fine with me - it was sort of a brainstorm to begin with. I found 2
> errors after I posted it, and looking at yours, I had a couple of other
> ones. (i.e.,
>
> Move sInputText (iLeadingSpaces + 1:iStrippedLength)
> ^^^^
>
It is also important to detect a string of all blanks. Because INSPECT is a
fairly heavy overhead you don't want to use it unless you HAVE to, so it
makes sense to check whether the field being passed actually HAS any leading
spaces before doing the INSPECT.
Did you understand the point that if the length is being passed,
OCCURS...DEPENDING is redundant and there is also no requirement for leading
spaces?
You could just move the literal you want centred to a string, and pass the
string and the length to the subroutine.
<snipped>
Pete.
Howard Brazee
On 7-Jun-2003, "JerryMouse" <nos...@bisusa.com> wrote:
> > Is there any interest in this clause that can be used in
> > working-storage? Or maybe an intrinsic function? I dug through the
> > free 2002 standard document I have, and the only "Center" I found was in
> > Report Writer. Does anyone other than me think that this would be
> > handy? I know we have an application for it where I work.
>
> There's probably more interest - especially from novices - in "Justified
> Right."
Justified Right confuses beginners, who figure it is something useful, like what
they use in word processors.
No, we've got to code in our justifications, fortunately with reference
modification, it is now easy.
Chuck Stevens
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3ee280d2....@news.optonline.net...
> The only things centered are page and column headings (on screen or
paper).
Not necessarily ...
> They're static. You do 'em once when you write the program.
ummm... no ... I know of programs that center the equivalent of the output
of the LOCALE-DATE function, for example -- but that is but one example
among many. Page headings are not necessarily static, be they on screen or
on paper, be they "hard-coded" or part of a RD.
-Chuck Stevens
LX-i
> "LX-i" <DanielJ...@Knology.net>
>>I must have missed this - what's the impending disaster with ODO?
>>
>
>
> It's the obvious: a wrong value can hose the cat.
>
> What's worse is that the runtime doesn't (usually/sometimes) check for a
> wrong value. For example,
>
> 05 MYFIELD OCCURS 1 TO 100 DEPENDING ON MYLEN PIC X.
>
>
> (implicitly moving 1,000,000 to MYLEN then...)
>
> MOVE SPACE TO MYFIELD
>
> makes one want to give up programming and open a pig farm.
>
> Better:
>
> 05 MYFIELD PIC X(100)
>
> (implicitly moving 1,000,000 to MYLEN then...)
>
> MOVE SPACE TO MYFIELD(1:MYLEN)
>
> at least contains the damage.
I've noticed that I can reference-modify my way into other variables,
since there's no checking for an out-of-range modifier (at least with my
compiler/runtime). You're saying that the expected behavior of the
above ODO would be moving spaces to MYFIELD and the next 999,900 bytes
of memory? That doesn't seem (to me) to be any more dangerous than
reference modification.
(why do I have the feeling that someone's going to reply "well,
reference modification is dangerous too!!!"?)
docd...@panix.com
LX-i <DanielJ...@Knology.net> wrote:
[snip]
>I've noticed that I can reference-modify my way into other variables,
>since there's no checking for an out-of-range modifier (at least with my
>compiler/runtime).
Well. truth be known... that's similar to how some folks managed to get
beyond the 32K limit for table-size away back in the Oldene Dayse. Would
someone else like to explain or shall I trot out Hoary Olde Example
#625... or was that #MCXXVI?
DD
LX-i
> "LX-i" <DanielJ...@Knology.net> wrote in message
> news:3EE3264D...@Knology.net...
>
>>
>
>
> Have a look at my response to your post in the "Is it possible to put any
> character (0 - 255) in a PIC X"
> thread
I found it... :)
> It is also important to detect a string of all blanks. Because
INSPECT is a
> fairly heavy overhead you don't want to use it unless you HAVE to, so it
> makes sense to check whether the field being passed actually HAS any
leading
> spaces before doing the INSPECT.
Also good points - I probably shouldn't have posted it in the state in
which it was, but it's proven to be a learning opportunity.
> Did you understand the point that if the length is being passed,
> OCCURS...DEPENDING is redundant and there is also no requirement for
leading
> spaces?
Right - I knew there were other ways to do it, I just thought it might
make interprogram communication cleaner. In other words, I wouldn't
have to say "You must have a Pic X(132) as the first parameter to this
call", I would say "The variable containing the text must be the length
of the second variable, up to 132 characters". I've had problems with
different-sized parameters before (on Unisys 2200).
Would it be any safer if I checked the input length (i.e., "If
iInputLength > 132 Go to Oh-Crap")?
JerryMouse
"LX-i" <DanielJ...@Knology.net>
>
> > Did you understand the point that if the length is being passed,
> > OCCURS...DEPENDING is redundant and there is also no requirement for
> leading
> > spaces?
>
> Right - I knew there were other ways to do it, I just thought it might
> make interprogram communication cleaner. In other words, I wouldn't
> have to say "You must have a Pic X(132) as the first parameter to this
> call", I would say "The variable containing the text must be the length
> of the second variable, up to 132 characters". I've had problems with
> different-sized parameters before (on Unisys 2200).
>
> Would it be any safer if I checked the input length (i.e., "If
> iInputLength > 132 Go to Oh-Crap")?
It's not only redundant - it is (in the main) misleading.
Passed parameters to subprograms do not, in general, inherit the
characteristics of the same data elements from the calling program - all
that is passed is the starting address of the calling program's data field.
You may do, in the subprogram, whatever you will with the address. For
example:
(caller)
WS
05 MyField occurs 100 pic x.
Call "SubPgm" using MyField(2)
(called)
Linkage Section
01 NewField Foo Pic X(1000).
Procedure Division using NewField.
MOVE SPACE TO NEWFIELD.
and you're probably screwed.
Peter E.C. Dashwood
"LX-i" <DanielJ...@Knology.net> wrote in message
> Peter E.C. Dashwood wrote:
> > "LX-i" <DanielJ...@Knology.net> wrote in message
> > news:3EE3264D...@Knology.net...
> >
> Also good points - I probably shouldn't have posted it in the state in
> which it was, but it's proven to be a learning opportunity.
>
It certainly has and has raised some very good points. It also gave me a
chance to bellow about ODO...<G>
<snip>
>
> Would it be any safer if I checked the input length (i.e., "If
> iInputLength > 132 Go to Oh-Crap")?
>
The code I posted does that, in effect, by assuming that if no non-blanks
are encountered before the stated length, then the input string is blank.
(Actually, the stated length could be incorrect but that's too grey an area
to worry about...)
There is an intrinsic function (2 of them actually, with Fujitsu) that will
allow you to check the length of stuff. (The second one is designed for use
with DBCS and Unicode). I'm not sure that I properly understand exactly how
they work (despite having read the manual...) because I had some unexpected
results from one of them tonight. I thought it was supposed to return the
number of characters in a field - the length.
I have a 20 byte field that can take a Credit Card number. I'm not sure that
ALL credit card numbers are 12 bytes ('though, going through my wallet it
looks like most of 'em are..<G>). What I want to do is move asterisks over
everything but the LAST four characters in the number. So I worked out
something based around this LENG function, hoping it would return 12 when
there were 12 characters and 16 if there were 16 or 8 if there were 8...you
get my drift. Instead it seems to be deciding that there are always 20 and
smothering the whole pot up to position 16 with asterisks. <G>.
If what it actually does is simply return the PIC size then it seems a bit
useless to me... I'll look at it tomorrow and see if I can enhance my
understanding <G>.
It would be a pity if I have to go back to the old tried and true
INSPECT...TALLYING.
Pete.
Peter E.C. Dashwood
"JerryMouse" <nos...@bisusa.com> wrote in message
news:fzadnael-Mh...@giganews.com...
>
>
> It's not only redundant - it is (in the main) misleading.
>
> Passed parameters to subprograms do not, in general, inherit the
> characteristics of the same data elements from the calling program - all
> that is passed is the starting address of the calling program's data
field.
> You may do, in the subprogram, whatever you will with the address. For
> example:
>
> (caller)
> WS
> 05 MyField occurs 100 pic x.
>
> Call "SubPgm" using MyField(2)
>
> (called)
> Linkage Section
> 01 NewField Foo Pic X(1000).
>
> Procedure Division using NewField.
> MOVE SPACE TO NEWFIELD.
>
> and you're probably screwed.
>
I'd say DEFINITELY screwed, but I guess you might just be lucky 1 time in a
million.
It is important to note that the above ONLY applies when passing BY
REFERENCE.
BY VALUE and BY CONTENT do not establish addressibility back to the CALLING
program. For this reason they are sometimes considered "safer", but there
are occasions when you need the results to be shared with the CALLING
program.
Personally, I ALWAYS make sure that parameters are exactly the same between
CALLING and CALLED programs, in format, sequence, and number, whenever I am
calling BY REFERENCE either implicitly or explicitly. I have always done
this (had it drilled into me by an older and wiser programmer who is now
maintaining the Cosmic Operating System at the big computer room in the
Sky...). Even though I now completely understand how it all works and know
what I COULD get away with, I still do what he taught me. As a result, I
cannot remember EVER having a problem with sub-program linkage.
Pete.
JerryMouse
"Peter E.C. Dashwood" <dash...@enternet.co.nz>
1. My Amex card is 15 digits long.(Aside: "I'm sorry sir, we don't accept
American Express. We'll be glad to take your Master Card or Visa." "So,
then, the difference between this establishment and a bait camp is not
great.")
2. If you're using something like:
Len = FUNCTION STORED-CHAR-LENGTH(CC-NUM)
Then "Len" should contain the length of the data in the field up to trailing
spaces. In the case of my Amex card, 15 (or, if recorded as nnnn nnnnnn
nnnnn, 17).
So, then,
MOVE '****' TO CC-NUM(Len - 4:4) should do the trick.
YukonMama
>Date: 6/7/03 8:09 PM Eastern Daylight Time
>But nobody uses justified right. Those who try to use it think it means
>something else, spending inordinate amounts of time and effort trying to get
>it to do something it wasn't designed to do.
>
>
Wander into my shop and remove all the Justified Rights you find. It is
favorite on our part number fields which are in just about every file, database
and report in the shop.
Sometimes we get lucky and it works :/
docd...@panix.com
Oh, I *cannot* resist...
... you mean it doesn't work... JUST RIGHT?
DD
William M. Klein
news:3ee5e...@news.athenanews.com...
>
<snip>
>
> Personally, I ALWAYS make sure that parameters are exactly the same
between
> CALLING and CALLED programs, in format, sequence, and number, whenever I
am
> calling BY REFERENCE either implicitly or explicitly. I have always done
> this (had it drilled into me by an older and wiser programmer who is now
> maintaining the Cosmic Operating System at the big computer room in the
> Sky...). Even though I now completely understand how it all works and know
> what I COULD get away with, I still do what he taught me. As a result, I
> cannot remember EVER having a problem with sub-program linkage.
>
> Pete.
>
>
'Tis the season to remind "readers" of a new feature in the 2002 COBOL
Standard - "CALL Prototypes". (Similar to features for "parameter checking"
available in other programming languages). For those interested in this
feature, see page 732 of the 2002 Standard, in the topic (of the "Concept"
annex),
"E.4.5.2.5 Prototypes"
If your "vendor of choice" does not currently support this feature, you may
want to contact them to find out if this is in their "development plans" for
the near future (before they provide a fully conforming 2002 Standard
compiler). Personally, I would guess that this feature - when/if
implemented - will avoid many "user errors".
--
Bill Klein
wmklein <at> ix.netcom.com
Peter E.C. Dashwood
I was confused between LENG and LENGTH and had missed STORED-CHAR-LENGTH
(which is the one I actually needed <G>)
They COULD input with spaces between the groups of numbers and I don't want
to forbid this, so I'll probably end up determining the length by the
traditional INSPECT ...function REVERSED method... unless STORED-CHAR-LENGTH
gives everything up to ALL SPACES?
I'll check it out.
Thanks again for the pointer.
Pete.
"JerryMouse" <nos...@bisusa.com> wrote in message
news:3IqcncIzENI...@giganews.com...
JerryMouse
> Thanks Jerry.
>
> I was confused between LENG and LENGTH and had missed STORED-CHAR-LENGTH
> (which is the one I actually needed <G>)
>
> They COULD input with spaces between the groups of numbers and I don't
want
> to forbid this, so I'll probably end up determining the length by the
> traditional INSPECT ...function REVERSED method... unless
STORED-CHAR-LENGTH
> gives everything up to ALL SPACES?
Yeah, it does. The function counts UP TO trailing spaces, not non-spaces in
the field:
xxxbxxxbbbbb... = 7
xxxxxxbbbbb... = 6
You'll probably want to treat cc numbers the same way we treat them (and
telephone numbers): rip out everything that's not a number, squeeze out the
spaces, and re-format the sucker the way you want it
123-456-7890 = (123) 456-7890 = 1234567890
Robert Wagner
>I have a 20 byte field that can take a Credit Card number. I'm not sure that
>ALL credit card numbers are 12 bytes ('though, going through my wallet it
>looks like most of 'em are..<G>).
In the US, nearly all are 16 digits. The first digit is the type of card:
3=Travel & Entertainment (AMEX, Diners, Carte Blanche), 4=VISA, 5=MasterCard,
6=Discover. I used to programming manager at one of the above.
LX-i
> It certainly has and has raised some very good points. It also gave me a
> chance to bellow about ODO...<G>
heh - glad I could be of service...
> If what it actually does is simply return the PIC size then it seems a bit
> useless to me... I'll look at it tomorrow and see if I can enhance my
> understanding <G>.
>
> It would be a pity if I have to go back to the old tried and true
> INSPECT...TALLYING.
Sounds like a need for a "trimmed length" component... :)
LX-i
>>Wander into my shop and remove all the Justified Rights you find. It is
>>favorite on our part number fields which are in just about every file, database
>>and report in the shop.
>>
>>Sometimes we get lucky and it works :/
>
>
> Oh, I *cannot* resist...
>
<groan>
Peter E.C. Dashwood
It is sorted now (thanks to some prompting from JerryMouse <G>) and the code
handles ANY length numbers.
Pete.
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3ee66258....@news.optonline.net...
Peter E.C. Dashwood
"LX-i" <DanielJ...@Knology.net> wrote in message
> Peter E.C. Dashwood wrote:
>
> Sounds like a need for a "trimmed length" component... :)
>
It isn't worth building such when there is already a function in Fujitsu
COBOL that does it.
I COULD encapsulate the whole process to a component that takes a credit
card number and returns it with all but the last four digits asterisked out,
but it's a bit of an overkill.
If the function was enhanced so that it also returned what KIND of card it
was and whether it was valid and not stolen, THEN it MIGHT be worth
componentizing...
Not this week <G>.
Pete.
YukonMama
>Date: 6/10/03 1:28 PM Eastern Daylight Time
>
>Oh, I *cannot* resist...
>
>... you mean it doesn't work... JUST RIGHT?
>
It always makes a gal feel good to know she's irresistable :)
Joe Zitzelberger
rob...@wagner.net (Robert Wagner) wrote:
FYI
The large associations (V/MC/AX) are all 16-digit and looking at 19- and
25-byte numbers in the future. 13-digit numbers have been history since
the mid-1990s.
However, private label cards, e.g. store credit cards, gas/oil cards,
still occasionally use 9 and 12 digit numbers for their private brand.
JerryMouse
"Joe Zitzelberger" <joe_zitz...@nospam.com>
> >
>
> FYI
>
> The large associations (V/MC/AX) are all 16-digit and looking at 19- and
> 25-byte numbers in the future. 13-digit numbers have been history since
> the mid-1990s.
>
> However, private label cards, e.g. store credit cards, gas/oil cards,
> still occasionally use 9 and 12 digit numbers for their private brand.
I PROMISE my Amex card is 15 digits!
JerryMouse
"YukonMama" <yuko...@aol.com> wrote in message
news:20030610131522...@mb-m16.aol.com...
Excellent! Finally an expert on Justified Right.
How do you use it?
I'm assuming it's not in the same class as LABEL RECORDS STANDARD.
docd...@panix.com
Gosh, what comes next... Geezer Flirtation? I can hear it now, down at
Pop's Chok'lit Shoppe, wheezed out as clearly as such lungs might...
... 'Can we get two straws for this Geritol Frappe?'
DD
Terry Heinze
built table sizes. For example:
xxxxxxxxxxxxxxxxxxxx TABLE SIZE: nnnn9 (zz9% FULL)
xxxxxxxxxxxxxxxxxxxx TABLE SIZE: nnnn9 (zz9% FULL)
I move the name of the table into the 20-character field JUST RIGHT and the
remainder of the display is aligned vertically.
--
....Terry
"JerryMouse" <nos...@bisusa.com> wrote in message
news:P6OdncMdkfd...@giganews.com...
Warren Simmons
Extract.
The instruction required a twelve bit pattern to AND/OR with the word
involved
to remove or isolate the part needed. It seemed so simple. Like me. But it's
how I
relate to all this yack about CENTER. Of course shift right and shift left
helped too.
Warren Simmons
YukonMama
>Date: 6/12/03 8:41 AM Eastern Daylight Time
>>
>> Sometimes we get lucky and it works :/
>
>Excellent! Finally an expert on Justified Right.
>
>How do you use it?
>
>I'm assuming it's not in the same class as LABEL RECORDS STANDARD.
>
No expert by any means :).
All the fields of part numbers and purchase order numbers are justified to the
right in all our files (or most of them). The reason for this is that the
systems were designed to accomodate the part number of a certain four letter
car company who is the largest customer. All other companies part numbers are
mangeled into place to accomodate this design (such fun).
In any event the intent of adding the JUSTIFY RIGHT clause on these fields was
to get around coding a justifing routine when data was entered on-line. It
doesn't work because in a lot of the screens (where btw the screen field is
also coded JUSTIFY RIGHT) there are underscores which prevents the
justification from happening and the routine is required.
Where the screens don't have underscores moving the data from the screen to the
record sometimes works, sometimes doesn't. Reason for this I have not
investigated (meaning does the sending field require trailing space or
low-values or does the receiving field require spaces or low-values).
As for the LABEL RECORDS STANDARD you'll find that in every program as well on
QSAM files and on some print files while other print files have LABEL RECORDS
OMITTED on them.
Arnold Trembley
Visa may still have a few active credit card account numbers that are
only 13 digits. I believe some of the cards in the Amex, Diners,
Carte Blanche group have fewer than 16 digits.
MasterCard accounts begin with 51 thru 55. There are no MasterCard
accounts beginning with 50 or 56 thru 59, and there is a
non-MasterCard company whose card numbers begin with 50.
All Discover Card numbers begin with 6011.
I believe there are a lot of 19-digit card numbers in Europe.
JerryMouse
Thanks.
Just so I'm clear, you use JUSTIFY RIGHT (JR) to get leading spaces in an
alphanumeric field. Further, you use JR to avoid coding your own justify
routines. However, there are known cases when JR doesn't work (field
contains underscores), and other cases where JR doesn't work for
as-yet-unknown reasons.
And even though JR doesn't work like you think it should (which was the
point of my original post), you use JR frequently.
OK.
And I don't doubt that you'll find "LABEL... " in every program in your
shop.
YukonMama
>Date: 6/13/03 8:34 AM Eastern Daylight Time
>
>Just so I'm clear, you use JUSTIFY RIGHT (JR) to get leading spaces in an
>alphanumeric field. Further, you use JR to avoid coding your own justify
>routines. However, there are known cases when JR doesn't work (field
>contains underscores), and other cases where JR doesn't work for
>as-yet-unknown reasons.
>
>And even though JR doesn't work like you think it should (which was the
>point of my original post), you use JR frequently.
>
>OK.
>
>And I don't doubt that you'll find "LABEL... " in every program in your
Yup - that's it in a nutshell. 'tweren't my idea - that's what's been there
since before my time.
I don't think DB2 has a JUSTIFY RIGHT so all the databases require a
justification routine when rows are created from keyed input, it's the VSAM and
flat file copybooks that contain the clause.
Personally I have a justification routine saved that I just copy into the
programs I write and don't bother thinking about the clause if I have a
copybook that contains one.
To the rest of the ng:
The above statement will probably trigger another 'debate' on copybooks, called
programs etc etc. Don't. I do what my shop requires, you do what your shop
requires, and we'll all be happy.
docd...@panix.com
YukonMama <yuko...@aol.com> wrote:
>>From: "JerryMouse" nos...@bisusa.com
>>Date: 6/13/03 8:34 AM Eastern Daylight Time
>
>>
>>Just so I'm clear, you use JUSTIFY RIGHT (JR) to get leading spaces in an
>>alphanumeric field. Further, you use JR to avoid coding your own justify
>>routines. However, there are known cases when JR doesn't work (field
>>contains underscores), and other cases where JR doesn't work for
>>as-yet-unknown reasons.
>>
>>And even though JR doesn't work like you think it should (which was the
>>point of my original post), you use JR frequently.
>>
>>OK.
>>
>>And I don't doubt that you'll find "LABEL... " in every program in your
>
>Yup - that's it in a nutshell. 'tweren't my idea - that's what's been there
>since before my time.
Wow... folks were putting the LABEL RECORDS clause in your CICS programs?
DD
YukonMama
>Date: 6/15/03 4:34 AM Eastern Daylight Time
>
>Wow... folks were putting the LABEL RECORDS clause in your CICS programs?
>
There were a few that had such - commented out as the original programmer found
out the program wouldn't comple - but they are still there. Selects, FD's and
all. Me thinks that maybe someone tried to clone a batch program. Most of said
programs have hit the obsolecence PDS now (they don't delete anything around
there) but I think there may be one or two still running.