• Subject: Re: Modify EBCDIC>ASCII xlate ta
  • From: D.BALE@xxxxxxxxxxxxx
  • Date: Wed, 24 Jan 2001 17:49:00 -0500

Scott, thanks again for the help!  This worked perfectly!  I am including the
bulk of your last post in a READ_ME source member that resides in the source
file with the WSCST source member for future reference.

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952

-------------------------- Original Message --------------------------

On Wed, 24 Jan 2001 D.BALE@handleman.com wrote:

> Thanks Scott!  I thought it might be this simple, but the Workstation
> Customization Programming manual was vague about this; couldn't tell if I'd
> have to translate all 256 bytes or what, and then, what to do with the other
> options.  I just wanted to change one frickin character, fer cryin' out
> >From the IBM AS/400 Printing V redbook: "Plan anywhere from one to five
> to complete a successful ASCII printer customization."  Don't think so!

Yeah, that book is really awful.  I figured it out mostly through trial
and error.

> What about the code pages?  How did you decide on 437?  (FWIW, this printer
> will used in the United States.)  Are you also printing to the datamax via
> tcp/ip?

Well, in my example I used 437 because thats the most common one in the
USA.  The same code should work with any codepage, provided that you
change the 'CODEPAGE = 437' line to whatever codepage you're using.

I'm not printing to the datamax directly via TCP/IP.  We have some
adapters (made by I-O Corp, model 4440S) that hook up to the printer via
twinax.  The adapters themselves look for a sequence of '&%02&%' and
replace it with an ASCII x'02'.  (Actually, you can put any hex string in
between the first &% and the second &%, and it'll make it that ASCII char)

Then, when I wanted to do TCP/IP I connected the printers to the serial
port of a Unix box, and wrote a filter for the Unix LPD that converts
those same codes the same way.

> I think you were being sarcastic when you commented on the IDEA 5250
> workstation doing the translation.  But just in case, I would not recommend
> this as an "easy" solution for anybody for a host of reasons.  Not that this
> tinkering with the WSCST has been easy so far, but it should solve a lot of
> problems for us moving forward.  As you might imagine, the dumb terminals
> the label printers attached are used in a warehouse environment by personnel
> not trained to respond to Windoze problems.

Thats not what I meant.  :)  I mean the idea of converting a '@' to an
ASCII x'02' with WSCST was something I could use...  not the idea of using
an IDEA 5250 terminal... :)

Tho, on that topic...  I'm in the same boat...  the people in our
production areas and warehouse are completely clueless when it comes to
Windows.  I much prefer a "dumb terminal".   Tho, I prefer the printers to
be directly attached to the network/twinax rather than going thru a
terminal or PC.

> Looking at this a little more closely...
> >     :ASCIICTL
> >       ASCII ='40'X
> >       DATA ='02'X.
> Is this translating an ASCII x'40' to x'02'?  If so, ASCII x'40' on my PC
> looks like the '(' character (the left parenthesis character).  Shouldn't
> be the ASCII value for '@'?  Oops, I see my mistake there, I was typing
> <Alt>-4-0 for x'40' when I should've typed <Alt>-6-4, i.e., decimal 64 =
> hexadecimal 40.

Well, this isn't a translation table per se.   (You can do a translation
table if you like, but then you'd have to code the entire table, not just
one byte)

Here's what the code actually does:

            identifies this as a host-print-transform WSCST source
         DATA = '20'X.
            when sending a 'space' to the printer, use ASCII code x'20'
         DATA ='0D'X.
            when sending a carriage return to the printer, use ASCII code
         DATA ='0A'X.
            when sending a linefeed, ASCII x'0a'

       Note that I do not specify codes for FORMFEED here.  On my
       datamax printers, a formfeed character can muck things up, so
       this effectively disables formfeed.  My label formatting software
       will send the datamax control codes to do the formfeeds itself.

           (interpret this as ASC CP INFO, it identifies the start of
            the ASCII code page info)
         CODEPAGE = 437
         DATA = ''X.
            This means that when the AS/400 wants the printer to use
            codepage 437, it has to send a special control sequence.
            The control sequence I specify here is ''X (nothing).
            In reality I'm only specifying this because its required
            for the :ASCIICTL keyword to know which codepage I'm
            referring to.
         ASCII ='40'X
         DATA ='02'X.
            The ASCIICTL parm is really intended for special printer
            functions that WSCST is not familiar with.  It provides you
            with an interface to put a "command" byte in the output from
            your HLL program, and have WSCST translate it to the proper
            control sequence for any specific printer & codepage.

            In this case, I'm telling it that ASCII x'40' is a special
            command byte, and that this printer needs to receive a
            x'02' to execute that command.

            Your "DATA" keyword can actually accept up to (I think) 256
            bytes to send to the printer... so this really isnt a
            translation table per se, but my way of tricking WSCST into
            converting '@' to Ctrl-B.
            end of ASCII code page info.
            end of WSCST source.

One thing to watch out for is the period.   Some statements stand alone,
like :ASCCPINFO.  for example.   See, it starts with the colon, and ends
with the period.

Other statements, such as :ASCIICTL are multi-line.  It still starts with
the colon, and ends with the period... But the period is 2 lines later.

Missing those periods, or putting them in the wrong place will cause you
grief. :)  Most likely, it'll just stop your code from compiling, but who
knows what other results it could have... :)

So have fun... :)

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.