Oracle E-Business Suite printing made easy with Pasta!

by Kenny Miller, Principal Consultant for Rocela

This one is for my fellow EBS veterans who’ve spent more time than they’d like to admit fiddling with application printer settings. Maybe, like me, you’ve been aware of Pasta but have been too busy to find out what it is and how it works.

Necessity is indeed the mother of all invention so, when recently faced with a challenging printing requirement, I was forced to find out all about Pasta. I liked what I found, so I thought I’d share my experiences with you.

The Requirement

My client is upgrading from R11 to R12. In R11, they only needed to print text output directly from the concurrent manager. However R12 comes with many more standard XML Publisher reports, so they now have a requirement to print PDF output.

My client also has hundreds of printers, from many different manufacturers and of different vintages! More specifically the requirement was:

1) Print all text and PDF output directly from the concurrent manager.
2) Print in PCL because:
a.  Not all printers support PostScript.
b.  Not all operating system print queues are enabled for PostScript, even for printers that actually do support it.
3) Minimise the amount of application set-up changes required.

So what is Pasta?

The following is taken from the System Administrator’s Configuration Guide:

“Pasta is an Oracle E-Business Suite utility that converts text report files to PostScript and also enables the printing of custom PostScript reports from Oracle E-Business Suite. The reports can then be directed to any PostScript printer.

Setting up your system to use Pasta is much simpler than the standard Oracle E-Business Suite printer setup procedure. The Printer Type, Printer Driver, and SRW driver files are provided. The only setup required to begin printing is the registration of the printer with Oracle E-Business Suite.

Many printing options can be defined using the Pasta configuration file (pasta.cfg). You no longer need to maintain multiple drivers and styles for each printer.

Pasta is provided as an executable named FNDPSTAX.”

I make no apology for copying this – it’s actually a good summary of Pasta. However the first paragraph only mentions PostScript i.e. converting text to PostScript, printing custom PostScript reports to PostScript printers etc. Mere mortals may have given up at this point, thinking Pasta is only about PostScript and isn’t able to do PCL. Yours truly is made of sterner stuff, and decided to have a look “under the hood” to find out what Pasta is really capable of.

PostScript or PCL?

Well, “out-of-the-box” Pasta actually does neither! All it’ll do is print text!

However, the Pasta configuration file does provide a “pre-processing” option, which can invoke any executable that supports an input file and an output file. Therefore, executables such as pdftops and acroread can be used to convert PDF’s to PostScript, or Ghostscript can be used to convert PDF’s to PCL!

The default configuration file is $FND_TOP/resource/pasta.cfg and by adding the following line to this file, PCL printing is enabled for both text and PDF output:

preprocess=gs -q -dNOPAUSE -dBATCH -sDEVICE=pxlcolor \

-dNORANGEPAGESIZE -sOutputFile={outfile} {infile}

In summary, this is using the Ghostscript executable (gs) to convert the input file to PCL. The device switch of pxlcolor tells Ghostscript to convert to colour output in PCL XL format. PCL XL (also known as PXL) is part of PCL version 6 which was released by HP in 1996, and should therefore be supported by all modern printers.

Problem Solved

My client is now able to print text and PDF output in a variety of different print styles, to printers from different manufacturers. To do this, all that was required was the following:

1) The change to pasta.cfg described above.
2) Changing the printer type to the seeded:
–PASTA Universal Printer Type
3) Bounce the concurrent manager.

Sounds too easy!

It would be very time-consuming to test all combinations of print styles and printer types; therefore you need to be realistic enough to expect the occasional anomaly. Pasta caters for exceptions by providing:

1) Printer specific configuration files.
2) Printer Driver specific configuration files which can be specified in the arguments for the Printer Driver.
3) A combination of Printer and Printer Driver specific configuration files!

If you’re able to successfully print output from the command line, then Pasta will be able print the same output from the concurrent manager.


I’ve found Pasta powerful but simple to use. If you already know your way round EBS printer set-ups then you’ll take to Pasta like a duck-to-water. Even if you don’t, it’s well worth investing some time to better understand it. It’ll be well worth it.


Oracle licensing for VMware

By Paul Bullen, Senior License Consultant, Rocela.

Recently, there has been renewed interest on VMware’s position regarding Oracle Certification, Support and Licensing.

This document lays out, amongst other popular Oracle-on-VMware topics, some logical and reasoned discussion about using DRS Host Affinity in order to limit Oracle license requirements within a VMware cluster. They suggest that limiting a VM to a particular physical host (or subset of hosts) within a cluster will reduce the license requirement and that only those physical servers require licensing for Oracle.

Understandably, this can have the potential to massively change your licensing requirements – the general stance has been that all physical nodes within a cluster, regardless of whether they are running a VM with Oracle on it, need to be licensed.

The VMware article is logical, interesting and its assertions are very positive, however it is worth remembering: this is a VMware paper. It is not underwritten by Oracle, and ultimately it is Oracle who decides how their products are to be licensed.

We work with clients using VMware and Oracle every day: we are unaware of any change of general stance from Oracle. Therefore, you should be fully aware of the potential licensing implications should Oracle audit your use of Oracle on VMware clusters.

Declaring an Oracle Unlimited License Agreement – Part II

Paul Bullen, Senior License Consultant, Rocela

My previous blog entry discussed the importance of making sure your staff understands what an Oracle ULA means to them and how they use Oracle software. I also mentioned that on-going management of your software deployment during a ULA is even more important than ‘normal’ licensing.

One of the reasons I mentioned tracking your software deployment during the entire term of the ULA was to ensure that you are getting the value you expected out of your investment. The other reason is so that you can accurately declare your usage of the ULA products when the Unlimited Deployment Period has finished.

To recap, with a ULA, you buy the right to use as much of the defined product as you wish during a set period (typically 3 years, but can be between 2 and 5 years), at the end of this period, you declare your usage of the product and this should become your perpetual license: your usage effectively ‘crystallises’ at this declared number and you then own that many licenses to do with as you would any other normal Oracle perpetual license.

If you do not track your usage throughout the term of the ULA, you may find yourself frantically undertaking an Oracle audit of your own usage on the run up to the declaration date: doing so may mean you ‘miss’ installations (and hence they are not licensed) or you count incorrectly. Measuring for an Oracle ULA is not quite the same as for ‘normal’ Oracle licensing—there are some small but important differences between the definitions.

Once you have measured your deployment (and let’s be honest, tracking and counting Oracle software accurately can be very difficult), you need to fill in a declaration form: this is what Oracle will use as the basis for your perpetual license. However, it is worth bearing in mind that there is a potential for audit at this point—understandably, Oracle need to be reassured you are actually using the software you are declaring to them and not just making up a number: they may ask to review your inventory and you should be prepared to share this with them. This is another reason to make sure you invest in this process and that you thoroughly understand your estate and the terms of the ULA.

As this is the last in the series of blog posts for ULAs, I’ll try and summarise:

• ULAs are a very powerful and beneficial (usually) way of licensing Oracle. They are significant purchases that require assessment and planning.
• You may use as much of the software as you like during the period of the ULA
• There is no true up, the opex and capex are set from the start
• Education and ‘awareness raising’ about the ULA is key to it being used correctly
• On-going usage tracking and management are even more important with a ULA
• ULAs are a significant investment and should be negotiated, managed and declared with expert advice

If you are considering a ULA and need to understand the basics, have a ULA and require assistance managing, or are approaching your ULA expiry and need help deciding on declaration or new purchase, then contact us for assistance. As you have been reading, we know a great deal about ULA’s and can steer you in the right direction.

Declaring an Oracle Unlimited License Agreement – Part I

Paul Bullen, Senior License Consultant Rocela

Last time we took a very high-level view of what you need to consider if you are weighing up purchasing an Oracle Unlimited License Agreement (ULA). Let’s now assume that your projections and the cost of a ULA make it worthwhile and you’ve gone ahead and entered into a ULA: well done! So what now?

Firstly, you must communicate the ULA purchase internally and what it allows the appropriate software users (anyone who can influence the amount of Oracle software your business will deploy) to do. It is important that full details of what the terms of the ULA and the products involved are passed on. Forwarding a copy of the Ordering Document to the DBAs is definitely not the best way to do this: DBAs generally won’t have the inclination to read the details of commercial documents! Instead, you must distil the content and tell people what products are available for unlimited deployment, and for how long they remain unlimited.

This seems obvious, but from our extensive experience working with customers who own ULAs, it is clear that often over 30 pages of ordering document can sometimes dangerously be interpreted as:

“Use as much Oracle software as you want!”

There’s a real danger that the actual allowance and detail of the ULA gets lost between those who negotiated it and those who ultimately use the software (this is a problem outside of ULAs as well, but the potential risk when the belief that all Oracle software is available for unlimited use is bigger).

So, assuming your staff know what products they can use and for how long, do you wait until a month before the ULA declaration date and then start preparing to declare? If anything, owning a ULA means you have to pay more attention to SAM and the amount of software you deploy and use: you need to know that you are following or exceeding your forecast – there is little point in having a ULA and not gaining the return you expected. In fact, there is a danger that you deploy far less of the software than forecast (e.g. change of product choice, cancellation of a project) and suddenly the whole business case for the ULA is no longer valid.

Your ULA is a massive investment for your company: it is worth putting effort and time into ensuring it is being used properly as well as having your methods and usage reviewed by an independent expert such as Rocela.

There have been a number of occasions where we have seen clients with a ULA who do not fully understand how to use them. I’ll keep repeating the same message:

A ULA allows you to deploy an unlimited amount of a set of products for a one-off upfront capital cost upon which the support is based. There is no true up; there is no change to the support fee (excluding RPI).

So, to summarise:

• Ensure your software users understand what the ULA allows them to use, and how

Track your Oracle software deployment: not just the ULA products but related products

• Ensure you compare your usage against your ULA business case

• ULAs are huge investments and should be properly managed and reviewed during their course

• Use your ULA: understand and take advantage of its features

Next time we’ll take a look at declaring your ULA in more detail. In the meantime, please ask any questions or leave any comments below.

Virtualisation – The Reality, not the hype. Final Part

By Tam Kyle, Senior License Consultant, Rocela

Before I launch into the thorny topic of Oracle licensing when virtualising, it’s probably worth reminding ourselves of what has been discussed beforehand … briefly!

So, Part I covered what virtualisation is and why companies are so keen to take advantage of it with Part II discussing the sort of problems organisations encounter when virtualising and at a high level, how you can avoid these issues in the future.

And so, to Part III – the impacts and considerations of Oracle licensing when virtualising. Where to start?

Cost saving or cost avoidance?
Let’s start with the obvious – money. What are you trying to achieve? Direct cost saving or cost avoidance? Do you actually know if it’s possible to reduce or avoid Oracle costs? If you have a fixed maintenance stream, then you are paying for what you have already bought irrespective of the actual amount of usage. Your support fees will not necessarily reduce in line with reduced usage – all you will have done is freed up licenses for use elsewhere in the business, all the while paying support for shelfware – but that might be beneficial to you as opposed to dropping the bottom line.

Your license contracts will determine whether and indeed how you can terminate licenses and it’s certainly not as easy as saying, “I’ve virtualised, therefore my footprint is smaller, so I’ll pay less.”

Smaller footprint
And whilst we are on that topic, are you sure that your footprint is smaller? In other words, have you considered whether your virtualisation technologies allow licensing in a sub-capacity context? In plain English, have you been able to establish whether you only need to license the bit of the box that you are using? As it turns out, this is not necessarily always the case. My fuller publication will walk you through a few scenarios with some surprising conclusions.

Server Clustering
One of the great benefits of some virtualisation technologies is the capability to join physical servers together (clustering). This allows for resilience and the seamless moving of virtual machines between hosts within the cluster. However the license terms underpinning this may prove prohibitive – for example, Oracle’s current stance on VMware is that you have to license all the boxes in the cluster because you are giving the VM’s the capability of roving. Many would argue that the VM is never in two places at once or that this virtualisation technology is ‘hard’ because it’s technically the same as Oracle’s, so why should they consider it ‘soft’ and force the entire cluster to be covered?

Have you considered that you may need to license your installation twice whilst you have parallel running during a migration to a virtualised infrastructure? Whilst this will most likely be a new and additional spend, it may not need to be licensed in the same way as your original setup.

Who said licensing was easy? In truth, there are many nuances around the various virtualisation/isolation/partitioning technologies in use – the breadth and licensing impact of these technologies isn’t easily understood and is frequently open to interpretation depending on the operational, business and contractual context.

The 3 Vital Treatments
Drawing this 3 part summary to a close, what we are saying – that virtualisation is an abstraction of hardware from operating systems and software. Organisations consider virtualisation to save money, provide operational flexibility and prepare for future technologies. Many organisations’ virtualisation projects run into trouble when they fall foul to unfixed requirements, underestimating the technical challenge, vendor support and lock-in and unintended licensing implications.

So, our 3 Vital Treatments, to keep in mind when embarking upon virtualisation projects are:
1. Get the requirements right – what is the purpose of the project? Have you consulted experts to see if you can save money and is it the optimal way to save money?
2. A tight business case – consider all elements. Understand the potential benefits and pitfalls of your virtualisation choices especially in license terms – how do you license your new virtualisation setup and how is it different from your existing license provision?
3. Control – understand migration needs and ensure you can operate your virtualisation setup ongoing, especially from a license perspective.

The full Virtualisation Publication will offer you much more detail and insight into this paradigm and is available to download from our website.

This concludes our series on Virtualisation – if you have any questions then please do not hesitate to email me on

Oracle Unlimited License Agreements – considerations for prospective buyers Part II

Paul Bullen, Senior License Consultant Rocela

Last time we looked at the basic principles of an Oracle ULA: for an up-front license fee, you can use as much product as you like, declare your usage at the end of the agreement and then own that amount of perpetual license. This time we’ll look at bit more at specifics for considering a ULA.

How much will it cost/is it worth it? Unsurprisingly, this is a very weighty question! This next bit will sound obvious: the key consideration is how much of the unlimited product you are expecting to use, and how much that would cost if you bought ‘normal’ perpetual licenses. Doing this requires some insightful modelling—we’ll look at a relatively simple example here.

Let’s assume we are embarking on a major business-changing programme. We have a basic but large requirement for Oracle Enterprise Edition Database and the Partitioning option. For the sake of clarity, it’s easier here for us to work with a small number of products at high volumes rather than a large number of products at lower volumes, though this may be slightly less realistic.

In order to be able to consider a ULA, I need to know what the likely total cost would be for these products and the volumes. After some calculations for ‘normal’ perpetual licenses, and applying a suitably appropriate discount, I have a potential bill of £1.3m license (capex) to cover this project’s requirements. Of course, if I could get a ULA for £1m, this would be a ‘no-brainer’, otherwise I need to start ‘hedging’ my bets – £2m could still be attractive if there are other quantifiable and realistic requirements in other areas of the business. Remember, the £2m capex would attract an annual support cost, let’s say 22%, of £440k per year – but for this £440k, we could actually use well over £2m worth of licenses. So, how do I build the business case to spend the £2m upfront?

There are a large number of variables to consider here:
• Likely cost of ‘normal’ incremental purchase
• ‘Known’ versus ‘unknown’ license requirements
• How much potential is there is fully utilise the ‘Unlimited’ component of the ULA?
• What degrees of certainty are there that certain projects will go ahead and make use of the products to the level forecast?
• Is there any chance of under-utilising the ULA?
• Discount levels for incremental purchases
• How much is the ULA likely to cost? (A fairly critical question!)
• What products need to be included in the ULA? How might your Oracle strategy change over the term?
• As with all Oracle licensing, working out the licensing requirement and purchase is dependent on both technical expertise (ensuring the correct license requirement is calculated) as well as commercial and financial expertise
• An absolutely critical point about a ULA is that your support cost is based on the license fee paid up front – NOT the amount you actually use

In order to answer all these questions accurately, we’d need input from a number of people within the business, from technical to strategy to architects to commercial stakeholders.

Do not let the number of variables put you off here: think about the potential value of a ULA and the flexibility and savings it could provide your business. Oracle ULAs are an excellent way to gain control of your Oracle licensing quickly and to provide your business with a clear strategy without worrying about additional licensing costs. Remember: you pay a ‘flat fee’ to use as much of the Oracle ULA products on the agreement as you like without any impact—no change to support costs, no additional capex.

Buying a ULA is not a trivial task – it is a significant purchase which needs proficiency in understanding Oracle licensing. It is well worth having the independent expertise of Rocela’s consultants to provide insight, lead you through the process, ask all the right questions and evaluate the ULA properly. Rocela’s consultants work with complex Oracle licensing situations every day and have helped many clients understand and manage the complexities of ULAs thoroughly.

Next time we’ll look at what happens once you have a ULA, and the associated management of licenses provided by a ULA. Please feel free to leave any comments below.

Virtualisation – The Reality, not the Hype. Part II

by Tam Kyle, Senior License Consultant

It’s been a few weeks since we posted our last blog (Part I) which covered what Virtualisation is and why companies are so keen to take advantage of it. In this piece, we will discuss the sort of problems organisations encounter when virtualising and at a high level, how you can avoid these issues in the future.

Remember, at the end of this series, we will publish a fuller Virtualisation publication written by one of our Senior License Consultants, Tam Kyle – this will offer you much more detail and insight into this paradigm , how to side step the common pitfalls, its impact on licensing and the ‘3 Vital Treatments’ for Virtualisation ROI.

So, why do organisations get themselves into hot water when it comes to virtualising their environment? From our Roundtable discussion hosted in November last year, and our day to day working with large enterprise organisations, we have obtained an insight into some of the most common areas that companies fall foul of when virtualising.

• Scope creep – Part of the problem with virtualisation is that when you actually get something delivered, it’s good – people want more and they want it now. Don’t be distracted by the potential of success – by all means entertain change to your scope, but do it formally.

• Understand your needs and objectives – there are many physical implementations of virtualisation technology, but they’re not all alike; advanced implementations will bring advanced benefits, but require advanced technology. Have you considered the potential financial impact in your business case?

• Vendor Support – does the Vendor support your applications on a virtualised stack?

• Migration – Many organisations underestimate the work involved in migration. Get it wrong and you’ve got a broken application as well as a set of disgruntled users.

• License implications of migration – Checking whether your vendor is going to require you to double up licenses for the duration of the migration is important or you may unwittingly fall foul of their licensing rules potentially incurring unbudgeted expense for license non compliance

• Vendor lock-in – Your application is running on virtualised platforms and infrastructure in such an abstract manner that you don’t even know where your data is anymore. For some organisations, particularly those with sensitive data, this might not be ideal. Also, what happens if you need to change vendor?

• Ongoing control – Virtualisation isn’t a silver bullet – you don’t just walk away when it’s done. You’ve actually added a layer to your setup, so who manages the virtualisation part ongoing?

Avoiding the common issues of Virtualisation

Obviously I could go on for some time on how to avoid these common issues – for the purposes of this post, I have kept this deliberately brief. Remember that there will be a fuller publication available for down loading from our website after we have posted Part III (probably in a week’s time).

Our approach would be to understand your requirements thoroughly – document these and obtain appropriate sign off. Make sure that your business case has senior sponsorship and similar sign-off. Accommodate changes, but do it within a formal change request process.

Match your needs to a product set, or more rightly, product sets. Don’t necessarily force yourself towards one vendor – you might need to swap at some point.

Understand the footprint you are attempting to virtualise and remember, it’s unlikely that you’ll achieve 100% virtualisation. Manage expectations accordingly.

Consider the fact that there are some applications that just do not sit well with virtualisation; some are too big, have special vendor configurations and are tightly bound to hardware layers. There are other applications that you would not migrate for non-technical reasons such as company culture, 3rd party vendors and internal governance for example.

In our final blog post, we’ll look at the thorny issue of licensing impacts, with particular focus on Oracle.

Subscribe if you want to be notified of its publication.

%d bloggers like this: