print immediate and duplex through AS/400

Hello,

Does anyone know if it is possible to force print to come out as duplex when doing a print immediate and the UBE runs on an as/400? If so, how did you do it? Thanks.

Jeremy,

It is not the 400, there is no way in JDE to print duplex. If you are using the 'new' method of printing (UseAdobe=1) in the INI there is no way to duplex, the PDF specifies simplex printing. If you use the 'old' method (UseAdobe=0) then no duplex/simplex info is sent to the printer.

What we do is we don't use the adobe print drivers and set the printer to duplex.

If you are using DBCS this is not an option and your out of luck.

We actually went through the process of building a job router that is attached to the QB7333 subsystem, this determins if the job needs old/new printing and gives it the proper INI.

Unfortunately I am not at liberty to say more about the process.

Hope this helps.

Tom

Thanks for the info. I received info from JDE earlier today that said that duplexing wasn't possible. They do have a SAR request in to make it possible, so my name was added to the list. Now, I'm just hoping some wonderful person on the list has found a way around it.

Hi tom , I want to ask you a question.I havent a problem like the one but I suppose you can help me maybe.ES is AS400820iseries V5R1MO ,jas serveris on AS400 ,too.We use websphere 3.5.5 on AS400.Deployment is on Win2000 server.I want to run ube on AS400 but can not see turkish characters correctly.We installed only Turkish language on deployment and we are generating all serialized objects selecting turkish language.We define a printer as PCL but I see still garbage characters on ubes.If I submit job from fat client to run on server nothing changes and I can see the characters correctly.Can you say something about this problem.. Best regards from Turkey.. Pelin Gürel

Pelinx,

Do you have the user ID that the UBE runs under on the AS/400 set to the CCSID that holds turkish? We actually have two JDE's: 1) JDE with CCSID 37 (English/Western European); and 2) JDEJPN with CCSID 939 (Japanese). If you use the wrong CCSID you get strange CCSID translation errors, you should see warnings in the AS/400 joblog that substitution characters are used.

Hope this helps.

Tom

Tom,
Are you putting this setting in the Network Queue Settings section of the
workstations jde.ini?

Is there a SAR or Tech Flash discussing this, was unable to locate it on the
KG.

Brent

Hi Tom ,thanks for your reply but we run on security based system.users can logon with their passwords but only jde access to database.I mean users access to AS400 with jde user.Jde user ccsid is 37.with this ccsid it is impoossible to see turkish characters on ubes that run on AS400 server.We only created users in ow with oneworld tools and can not see users in AS400 command (wrkusrprf).Best regards.Hope you can help me

Re: RE: print immediate and duplex through AS/400

Brent,

I finally got tiem to log into my ES. The attribute is in the [UBE] section and is as follows:

UBEUseAdobe=1

or

UBEUseAdobe=0

Hope this helps.

Tom

pelinx,

I understand your issue, but your desires and what is technically feasable are opposed to each other. If the user must access turkish characters, he MUST have a system user id that is set to the turkish CCSID. Not good news I know, but the way it is. This is one of reasons that we use the JDE & JDEJPN user id's for our system users. We do not publish the password, so the users cannot use the JDE profiel to access data. Those that need to access data outside of OW, have their own user ID on the AS/400.

Having multiple ID's and common ID's is a pain, but part of the overhead of multi-instance.

Hope this helps.

Tom

Hi tom ,I will talked to my direvtor about it,thanks a lot.And I also one question for you.As far as I understand from our correspondings you can see chinese characters in your database and you can access data with a ccsid diffrent from 37.It is okey for you ,isnt it? But unfortunately I can not see
turkish characters on AS400.I can only see them in oneworld.
one world table ccsid 's are 37 but IBM suggest to use ccsid 1026 to see turkish characters.But when we want to use 1026 installation failed because of not creating some table fields such as req# field.Can you understand my problem now?So we have use ccsid 37 in installation on as400.But now as you see, we can not see characters in database correctly.Did you meet a problem like this in installation, I wonder? kind regards ..Byee

Pelinx,

I am making the assumption that JDE recommends CCSID 1026, check with JDE first for the correct CCSID.

I belive that the issue is that some special characters, in this case # either is not supported in 1026, or JDE middle ware has a bug in it.

I am also assuming that fields such as req# are base JDE and not fields you created, if you created the field, change the name to use ONLY upper case letters and numbers, these exist in every CCSID/CodePage that you would reasonably use.

As far as how the data actually looks in the database, using DSPPFM I always see a bunch of 'garbage' characters, do it long enough and you will be able to recognise turkish in single byte, the same way I can tell japanese & chinese in single byte.

If you need to see the data in green screen, the only way I have been able to do this is to use a machine with the correct code page, and install Client Access for that language.

Hope this helps.

Tom Davidson

hi tom it is me again sorry to call you again and again.But nobody has helped me except you.I searched knowlegde garden and speak most of jde consultants but nobody can help me.So I did what you have done.I created a jdetr user profile with ccsid 1026 as as400 recommends.And also in ow I created the same user.And I submit ube to run on server with this user.But nothing has changed.I think it is what you have done in your system isnt it?do you have anything to advise me to do?Best and Kind regards from Turkey...

The data you entered with codepage 37 will not be correct and will have to be reentered - the characters you need from 1026 are not available in 37 and will not even really be in the database except as the "substitution" character. I'm surprised you didn't have this info, I recall it being pretty easy to find in the documentation.

You need to call JDE and ask for all information on Tier 3 language configuration, and then mention Turkish. There are some other requirements after you get the database right to be able to see the data in PDF files correctly.

Upload all the arial.ttf , ariali.ttf, arialbd.ttf, arialbi.ttf, times.ttf, timesbd.ttf, timesi.ttf, timesbi.ttf, cour.ttf, courbd.ttf, couri.ttf, courbi.ttf from your PC to the server's resource/truetype directory. Yes, the AS/400 will actually use the truetype fonts! If you use FTP, make sure you do this in binary mode. Delete (or move) the "fonts" directory from the resource directory, because the Type 1 fonts there do not have the glyphs to be able to render Turkish Characters, and JDE will use these instead of the TTFs if they are still there. Additionally, I've had to delete the fonts directory on my client workstation's Acrobat install in the Program Files directory. Then it should work. I believe this is ALL in a document on "Tier 3 language configuration" but I don't have it handy. I'm sure it is on the KG somewhere, or available via phone call. That is how I got the info a bit over a year ago when I was actually working on a Czech install (ccsid 870 for me).

You will know if the data in the PDF is right even if the fonts are wrong if you open the PDF in wordpad and view the data parts and they are correct. If this happens, then only the font stuff above is needed to be done. If the data are still wrong in wordpad, your database may still have problems.