Hello Joe!

20 Jun 26 15:46, Joe wrote to all:

On Sun, 14 Jun 2026 17:11:00 +0100, "Vincent Coen" <VBCoen@gmail.com>
wrote:

<1781027365@f1.n250.z2.fidonet.ftn>
<rqqq2l9i9q1pksmd87thkq3ktm8ca1skap@4ax.com>

Hello Joe!

13 Jun 26 15:43, Joe wrote to all:

When I started out Cobol was coded on coding sheets (25-30 lines a
page ???). These would go to data entry & we'd get a box of
punched cards back. Sequence numbers WERE important because they
would help you find/fix/replace the cards with errors. We'd have

to

punch those out on a rinky-dink punchcard maker & fix the full

deck

after which operations would read the fixed deck back in, run a
compile, get you the listing & the circus would start over again.
Yes, sequence numbers had a purpose.

Back then we had 2 terminals for 25 IT personnel, The juniors did

not

get to use those very easily ;)

On Tue, 09 Jun 2026 18:49:25 +0100, "Vincent Coen"

<VBCoen@gmail.com>

wrote:

Line number or more importantly sequence numbers, as pointed out

in

another post, is for when punched cards was the primary input

method

for source decks (yes paper tape as well - but spot the obvious
difference) and for the instance when some one dropped a box

(2,000,

80 column cards max) on the floor so collecting then all and

placing

then the correct way round (they have a cut out in one corner)

they

can now be input into a card sorter (columns 1 thru 6) so they

will

be in the correct order.

Now for many m/f vendors no real problem changing to say Free

format

but for IBM where there PDS data system is based (generally) on

fixed

format size of 80 bytes there is a major issue, to put it mildly

but

this is fixable for allow VB (Variable format sizes) and for this

to

be available to the compilers.

Why not , ask IBM (note I have not worked on IBM kit for many

years

despite having access to MVS, OS390 etc under Hercules but as I

have

not had a IBM client for some time they are very old versions.

Yes, I remember the use of Cobol coding sheets, ditto for Print
layout forms (now sadly not available).

Like you and for almost all that had that system they went to the key
punch team and we got back a box or more/less of cards that with a
job sheet was sent to the computer room for processing then we ending
up with a listing that had errors on and if only a few we would punch
own own corrections on using a real IBM 029 punch or a hand punch for
just a small number of cards. The benefit of using the 029 punch was
the text was printed at the top of the card - not so for the hand
punch :( You then replaced the wrong cards with the corrections then
the whole cycle started again and this was often a two day turn
around although mostly on the old kit say IBM 1401,7074 & 360/370.

Production improved dramatically once programmers could key a source
program directly in via a terminal or RJE type kit.

I find it a lot quicker now using a micro running a complier and
doing the same directly and once working sending the source to a
mainframe before running a quick compile to confirm all is well with
the world.

I did have a try and taking the source code directly in to a micro
but that creates even more issues when it does not get the correct
words - only tried that the once.

Back to layout forms - The printer layouts would be useful when
setting out some of my accounting systems specifically the one's that
use pre-printed forms such as tax returns of one type or another and
ditto for pay slips et al - I will be using plain paper and adding in
headings as needed. I am trying to make it as easy as possible for
users to change the set ups for reporting by using RW but there are
some functions that are missing in GnuCobol RW sub system so some
elements have to be done the old way :).

Needless to say the original code uses a line printer or matrix with
continuous stationery so has to be changed for the more modern types
such as inkjet, inktank and laser printer. Needless to say I did look
for one via ebay and could not believe the silly prices for very
basic ones. Should have kept my 2 heavy duty ones with stands but my
study was getting short of space :(

Vincent

I don't remember us having a hand puncher, there was an old puncjing
machine tucked away in a corner with the data entry girls - not meant derogatory as they were able to do many tasks at the same time which I
could only dream of ;)

I've printed complete (landscape) legal size "dynamicly" created forms (blocks, boxes, columnar) from Colbol on a (I believe) Xerox page
printer using a specially created font. Every page unique due to
customer requirements... Talk about people "understanding"..... Man,
those were the days....

I have done some light reading on looking for any HP printers than can
handle being sent escape sequences to change font but HP have not produce
any docs since 1995 - it looks like another dying art form.
I had a HP 4000 laser that could do that and receive a template (image)
that was printed along with the normal text sent to print.
Had to sell it off as getting a wee bit too old although then using a ink
jet has its own problems - mostly cost of ink etc. Now use a ink tank and
no does not have such facilities - at least according to HP tech.
support....

Hand punch :
If it works, I have attached? a jpg of one from ICT later renamed as ICL.
One I used was a lot younger :)

Could not find one from IBM.

Another devise helped put a chard into a hole created in error.

I do not recall using one as that method was banned when using fast card readers, i.e., air flow could suck them out.

Vincent



SEEN-BY: 25/0 21 250/0 1 2 4 5 7 8 9 13 14 362/6 371/52 712/1321

On Sun, 21 Jun 2026 15:39:42 +0100, "Vincent Coen" <VBCoen@gmail.com> wrote:

Hello Joe!

20 Jun 26 15:46, Joe wrote to all:

I have done some light reading on looking for any HP printers than can
handle being sent escape sequences to change font but HP have not produce
any docs since 1995 - it looks like another dying art form.
I had a HP 4000 laser that could do that and receive a template (image)
that was printed along with the normal text sent to print.
Had to sell it off as getting a wee bit too old although then using a ink
jet has its own problems - mostly cost of ink etc. Now use a ink tank and
no does not have such facilities - at least according to HP tech.
support....

Hand punch :
If it works, I have attached? a jpg of one from ICT later renamed as ICL. >One I used was a lot younger :)

Could not find one from IBM.

Another devise helped put a chard into a hole created in error.

I do not recall using one as that method was banned when using fast card >readers, i.e., air flow could suck them out.

Vincent

I assume you mean https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Machine=

Been looking but as it's been some 45 years ago & I hated using it I forgot what ours looked like. I feel like similar to
https://twobithistory.org/2018/06/23/ibm-029-card-punch.html It definitely had a keyboard.....

As far as HP printers: The "trick" was to send the characters not as HP escapes but as a string of EBCDIC characters from Cobol. To
get to the "form" font and subsequently fill the form would mean: Switch fonts, print the formline without a line feed, swicth fonts
to character font, print the texts/numbers/prices. A lot was hard-coded in Cobol as "weird" looking strings which made maintenance
by those "not in the know" quite difficult as part of the storage was in lower case in a time where TSO (or whatever version control
in Cobol like Panvalet) profiles usually defaulted the members to uppercase.

As a check the first lines were something like: "If these characters are not in lower-case you have a problem & you should stay
away from this program".

--- MBSE BBS v1.1.7.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

In article <vthk3lt135baa8p7pml0a3p5khmp33okmh@4ax.com>,
Joe <none@nowhere.whereo> wrote:

[snip]

As far as HP printers: The "trick" was to send the characters not as HP >escapes but as a string of EBCDIC characters from Cobol. To
get to the "form" font and subsequently fill the form would mean: Switch >fonts, print the formline without a line feed, swicth fonts
to character font, print the texts/numbers/prices.

You mean the nightmare-haunting WRITE PRNTLIN33 FROM WS-PRT-DATALIN02 WITH
NO ADVANCING? I believe that was deprecated with the '85 Standard.

A lot was hard-coded
in Cobol as "weird" looking strings which made maintenance
by those "not in the know" quite difficult as part of the storage was in >lower case in a time where TSO (or whatever version control
in Cobol like Panvalet) profiles usually defaulted the members to uppercase.

As a check the first lines were something like: "If these characters
are not in lower-case you have a problem & you should stay
away from this program".

The need for this was always 'someone new in a corner office'. They'd
come in and complain that at OtherCorp they could get stacks of paper with subscripts and superscripts and midstream font changes and now...
expecting them to do their jobs without such illuminated texts was cruel
and unusual.

First they'd buy the printers. Then the corner-office crew would go to
all the training classes (held in Las Vegas, Nev. or on shipboard near the Bahamas), come back and toss the stacks of manuals into someone's lap and complain more about 'I don't know what your problem is'.

As I recall there were two ways to deal with these unanticipated
control-code secuqences. The best way was to have learnt how the TSO
editor could deal with such depths with no changes at all, a simple

05 WS-PRT-DATALIN02.
10 WS-PRT-DATLIN02-CNTL-CHAR PIC X(02) VALUE X'ABFF'.

.... which, of course, would require the New Guy to go through all the code when the hardware got updated. The other way was to throw CAPS OFF and
HEX ON and enter the values into the card image directly.

COmmon Business Oriented Language. Not COmmon Print Formatting Language
but that didn't stop anyone. Someone who used to frequent these parts - perhaps Mr Dashwood? - would tell a take about how a Corner Office Idiot
said 'I can use my son's Amiga to insert a photo of a new signature for
The Secretary, why can't the big iron?'

(Such folks didn't like 'You have to give us the money for it. This code
was written in 1976 and has been running, flawlessly, ever since. The JPG format became a standard in 1992 and budget for mods was requested in '94
and turned down in '96... and again requested in '97 and turned down for Y2K... and again requested in '06 and turned down because 'we're moving to Novell, like everyone else'... and other times. This takes time, money
and work.'

DD

--- MBSE BBS v1.1.7.2 (Linux-x86_64)
* Origin: Public Access Networks Corp. (2:250/1@fidonet)

On Wed, 24 Jun 2026 16:11:45 -0000 (UTC), docdwarf@panix.com () wrote:

In article <vthk3lt135baa8p7pml0a3p5khmp33okmh@4ax.com>,
Joe <none@nowhere.whereo> wrote:

[snip]

As far as HP printers: The "trick" was to send the characters not as HP >>escapes but as a string of EBCDIC characters from Cobol. To
get to the "form" font and subsequently fill the form would mean: Switch >>fonts, print the formline without a line feed, swicth fonts
to character font, print the texts/numbers/prices.

You mean the nightmare-haunting WRITE PRNTLIN33 FROM WS-PRT-DATALIN02 WITH >NO ADVANCING? I believe that was deprecated with the '85 Standard.

Yes my friend. This was around 1989 when the '85 standard in this organisation was not present. The company - no longer in
existance - for more reasons than one always makes me think of Tom & Jerry/Roadrunner as part of their name was ACME ;)

A lot was hard-coded
in Cobol as "weird" looking strings which made maintenance
by those "not in the know" quite difficult as part of the storage was in >>lower case in a time where TSO (or whatever version control
in Cobol like Panvalet) profiles usually defaulted the members to uppercase.

As a check the first lines were something like: "If these characters
are not in lower-case you have a problem & you should stay
away from this program".

The need for this was always 'someone new in a corner office'. They'd
come in and complain that at OtherCorp they could get stacks of paper with >subscripts and superscripts and midstream font changes and now...
expecting them to do their jobs without such illuminated texts was cruel
and unusual.

First they'd buy the printers. Then the corner-office crew would go to
all the training classes (held in Las Vegas, Nev. or on shipboard near the >Bahamas), come back and toss the stacks of manuals into someone's lap and >complain more about 'I don't know what your problem is'.

As I recall there were two ways to deal with these unanticipated >control-code secuqences. The best way was to have learnt how the TSO
editor could deal with such depths with no changes at all, a simple

05 WS-PRT-DATALIN02.
10 WS-PRT-DATLIN02-CNTL-CHAR PIC X(02) VALUE X'ABFF'.

... which, of course, would require the New Guy to go through all the code >when the hardware got updated. The other way was to throw CAPS OFF and
HEX ON and enter the values into the card image directly.

COmmon Business Oriented Language. Not COmmon Print Formatting Language
but that didn't stop anyone. Someone who used to frequent these parts - >perhaps Mr Dashwood? - would tell a take about how a Corner Office Idiot >said 'I can use my son's Amiga to insert a photo of a new signature for
The Secretary, why can't the big iron?'

(Such folks didn't like 'You have to give us the money for it. This code >was written in 1976 and has been running, flawlessly, ever since. The JPG >format became a standard in 1992 and budget for mods was requested in '94 >and turned down in '96... and again requested in '97 and turned down for >Y2K... and again requested in '06 and turned down because 'we're moving to >Novell, like everyone else'... and other times. This takes time, money
and work.'

DD

The company wanted something like this, me as the contracter thought: Ow, that sounds like a nice challenge and something I haven't
done before - why not.... So the reply was: Well, yeah, if the printers guys cooperate, why not. And that was the start of the
story. There is a lot more to tell but I don't want it to get to identifying ;) Not the end of the bussiness though, that was the
subsequent off-shoring.

--- MBSE BBS v1.1.7.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)