Re: Modify EBCDIC>ASCII xlate ta

[D.BALE@xxxxxxxxxxxxx]

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
 loud.
> >From the IBM AS/400 Printing V redbook: "Plan anywhere from one to five
 days
> 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
 with
> 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
 this
> 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:

       :WSCST DEVCLASS=TRANSFORM.
       :TRANSFRMTBL.
            identifies this as a host-print-transform WSCST source
       :SPACE
         DATA = '20'X.
            when sending a 'space' to the printer, use ASCII code x'20'
       :CARRTN
         DATA ='0D'X.
            when sending a carriage return to the printer, use ASCII code
            x'0D'.
       :LINEFEED
         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.

       :ASCCPINFO.
           (interpret this as ASC CP INFO, it identifies the start of
            the ASCII code page info)
       :CODEPAGE
         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.
       :ASCIICTL
         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.
       :EASCCPINFO.
            end of ASCII code page info.
       :EWSCST.
            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
+---