Introduction to the AS/400 - CODE Editor

greasyservantInternet and Web Development

Jul 30, 2012 (5 years and 11 months ago)


Introduction to the AS/400

CODE Editor



In this chapter we will demonstrate how to perform common programmer functions using
CODE Editor. In addition, we will compare CODE Editor to the iSeries native
Application Development Tools (ADTs) and explain the relative advantages and
dvantages to each.

At the end of the chapter you should understand:

The difference between verifying and compiling


The advantages and disadvantages of CODE Editor vs. the iSeries ADTs

At the end of the chapter you should be able to:

Enter and S
ave source code on a PC and an iSeries

Verify source code

Compile source code

Vertically split a screen

Control the appearance of an edit session

Introduction to the AS/400

CODE Editor


IBM’s WebSphere is a new set of PC
based application development tools (ADTs) for
the iSeries. The WebSphere

ADTs (which include CODE400, Studio, and Visual Age
Java) provide all the capability of the iSeries native ADTs (PDM, SEU, SDA, etc.), as
well as, the ability to create software applications for non
iSeries computers (I.e. PCs).
For instance, a programme
r can create PC
based JAVA programs that display and
retrieve information from web pages and then call iSeries based RPG programs.
Programmers would use WebSphere Studio to create the web pages and GUI interfaces,
Visual Age Java (VAJ) to create the PC Ja
va programs, and CODE400 to create the RPG
programs that run on an iSeries. The iSeries native ADTs don’t have the capability to
create this type of “cross platform” application.

The functions found in the iSeries native ADTs are provided by two CODE400
applications, CODE Editor and CODE Designer. However, there are major differences
and improvements with CODE400. We will cover many of the new features, as well as,
some familiar functions that work just a little differently.

Entering and Saving Source


You can think of CODE Editor as the PC version of SEU. Notice (in figure 1) the
column numbers across the top of the source code entry area and the line number area on
the left side of the screen. Look familiar?

Figure 1

Introduction to the AS/400

CODE Editor


When a CODE Edito
r session is started, the cursor is placed at line 1 column 1. To enter
source code, simply start typing and then save the file. To save a file, click on the menu

option and then click on the

option in the drop down menu. (See
figure 2.
) The “Select file

Save as” window will be displayed. (See figure 3.)

Figure 2

Figure 3

This window allows you to save the source code to the PC’s hard drive. In the directory
pane (on the left side of

the window), double click

to display a tree diagram

Introduction to the AS/400

CODE Editor


of the PC’s drives. Double clicking a drive letter, displays all the files and folders in the
drives root directory. (See Figure 4)

Figure 4

In this example, a folde
r (

has already been created on the C drive to hold our
future iSeries objects. Double clicking on

(see figure 5) shows that the folder is
empty because the content pane (located to the right of the directory pane) is blank.

Figure 5

Introduction to the AS/400

CODE Editor


To save the source code, replace the

that appears in the file name text area (at the top of
the window) with the name of the source code file


In the description text
area (at the bottom of the window) enter the member
type, in this case, CLP. Click the
OK button, in the lower left of the window, to save the source code in the file

within the


A better method to create and save source
code is to start by clicking on

. Enter th
e source code type at
the New window (figure 6). Identifying
the type of source code enables CODE
Editor to perform syntax checking as the
source is entered. In the example, we will
specify the type as PF, meaning we are
going to enter DDS source code th

Figure 6

defines a physical file.

Select the source type by clicking on the
on the text box arrow button and selecting
a type from the drop down list. In this
case PF, as seen in figure 7.

After clicking on the source type, click the
utton (in the lower left of the New
window). This will start a new editing
session (see figure 8).

Figure 7

Figure 8

Introduction to the AS/400

CODE Editor


Notice that the format line is specifically for a PF definition rather than the default
column numbers as seen in fig
ure 1.

Figure 8 provides a detailed break down of the CODE Editor window. Many of the areas
are similar to an SEU edit screen (for instance, the line number and source code areas).
Other areas (for instance, the tool bar and menu bar) are similar to tho
se found on the
5250 emulation window (covered in chapters 1 and 17) and the iSeries green screens (the
message line and command line).

Many of the commands and functions available in SEU (save, retrieve, browse) are
available through the tool and menu ba
rs. In addition, standard window functions such as
copy and paste can be accessed. CODE Editor also supports all the SEU line number
commands (I
insert, D

delete, CC

block copy, etc.).

There are also many differences with CODE Editor. For instan
ce, when you press the
return key a line is inserted (unlike SEU where the cursor is simply moved to the next
line). Also, the command line in CODE Editor is used to issue editor commands not CL
commands. In this sense the CODE Editor command line is mor
e similar to the SEU
command line (found at the top of the SEU edit screen) than the command line found at
the bottom of most green screens.

Another difference is the two seemingly identical methods (
Close view

on the

command menu) to end an

edit session and save source code. Both options do end
the current editing session and save the source code, however, if multiple source files are

will close all editing sessions.
Close view
, on the other hand, only closes the
current editing

session. In addition,

actually ends the CODE Editor application. If
only one source file is open and
Close view

is selected, it only appears that CODE Editor
is ended. In actuality, the CODE Editor user interface is hidden. This means that if
DE Editor is selected again, it will re
open faster.

To move between editing sessions, click the file list arrow button (see figure 9) to display
a drop down list of editing sessions (identified by the file name). Simply click on the file
name to brin
g up its editing session.

You may have noticed another big difference with CODE Editor

source code is
displayed in multiple colors. In “IBM
ese” this is called “token highlighting”.
Essentially CODE400 uses “color coding”, underscoring, italics, etc
. to differentiate
between types of source code statements (for instance, comments vs. executable
statements), as well as, different sections within a source code statement (the command
word vs. keywords). This makes the source code easier to read and und
erstand. For
instance, programmers can quickly find the executable statements in a program by
ignoring all the red comment statements. CODE400 applies “token highlighting” after a
line of source code is entered not as it is typed.

Introduction to the AS/400

CODE Editor


gure 9

Of course, different languages have different “token highlighting schemes”. For instance,
figure 10 shows an example of JAVA source code and figure 11 shows some DDS source

Figure 10

Introduction to the AS/400

CODE Editor


Figure 11

Notice that com
ments are green in both but in JAVA comments are also italicized. Purple
is used in both but in JAVA purple indicates character strings while with DDS it indicates
function area parameters.

Defining the source code type before entering the source code
has several other
advantages (in addition to token highlighting). We will cover three of them: prompting,
syntax checking, and the Verifier.


Most prompting in CODE Editor is as easy as SEU

press F4 and a prompt will be
displayed. However,
CODE Editor does not support as many languages as SEU and its
CL prompting is awkward to implement and use. The CODE Editor prompts are “GUI
ed” versions of the green screen prompts. For instance, instead of input areas and
constant text fields the promp
ts are dialog boxes with text areas, drop down lists and
buttons (see figure 12).

Figure 12

Introduction to the AS/400

CODE Editor


Of course, the prompt windows are different depending on the source code language (and
even source code version) being entered. For instance, pro
mpting for a RPG command
results in the RPG/400 Specification Selection dialogue box (figure 13). It is completely
different from the DDS prompt in figure 12.

Figure 13

RPG requires a specification type before getting a command
prompt. For example,
clicking on the radio button for a C spec (Calculation specification) would result in the
prompt seen in figure 14.

Figure 14

Introduction to the AS/400

CODE Editor


RPG prompts, however, have differences depending on the version of RPG you are
entering. If

the source code had been defined as RPGLE (an ILE RPG program) the
specification selection dialogue box in figure 15 would have been displayed. Notice that
there are two types of C specs that can be selected versus only one type in figure 13.

Figure 15

CODE Editor CL prompts are actually displayed in a 5250 emulation session. To prompt
for CL commands, you have to start a 5250 emulation session, sign onto an iSeries, and
then start a “STRCODE Server”. In addition, the current librar
y (of the iSeries session)
must be a user library, not a system library (like QGPL).

Figure 16 shows the iSeries Main menu in a Mochasoft 5250 emulation window with the
DSPLIBL command to display the current library. Figure 17 shows an example of the
“Display Library List” screen. Notice in the figure that the user library YOURLIBXX is
defined as the current library. After making sure the current library is a user library, you
would issue the STRCODE command from any command line. An “interactive s
session will be started and the screen in figure 18 will be shown.

Using CODE Editor, start a new editing session for a pgm (with type defined as CLP).
When a CL command is entered and prompted for (F4), the green screen prompt will
appear in the
emulation session window. Fill in the parameters and press Enter. The CL
command and its specified parameters will be placed into the CODE Editor session.

Introduction to the AS/400

CODE Editor


Figure 16

Figure 17

Introduction to the AS/400

CODE Editor


Figure 18

Syntax Ch

As source code is entered, the CODE Editor online syntax checker highlights errors and
inserts messages into the source code. For instance, figure 19 shows a misspelled device
name in an RPG program and the error message (in pink).

Figure 19

Correcting the error will remove the message and allow you to enter another line of code.
Figure 20 shows the corrected statement with additional statements and another error.

Introduction to the AS/400

CODE Editor


Figure 20

Syntax checking does not work the same
for all languages or errors. For instance, line
number 11 in figure 21 contains a DDS specification that has been misaligned. Notice
that certain portions of the statement have been highlighted in red but no messages have
been inserted.

Figure 21

To get more information about an error, move the cursor to a highlighted area and invoke
online help by pressing F1. The PC’s default browser will be started and a web page with
context specific help will be displayed. In this case, we posi
tioned the cursor at column
17 (the specification type field) and therefore figure 22 was displayed.

The syntax checker can sometimes be overly helpful (like a backseat driver is “overly
helpful”). For instance, the syntax checker will often display err
or messages as a line of
code is changed. This would be like a word processing spellchecker highlighting words
as incorrect as they are typed in. When making many changes you might want to turn the
syntax checker off. The syntax checker can be toggled
on and off easily by clicking on

Introduction to the AS/400

CODE Editor


Figure 22

Though the syntax checker and online help are helpful, they don’t always provide enough
specific information to help the programmer find the e
rror. In addition, even if the syntax
checker doesn’t find any errors, it does not mean the code will compile successfully.
That’s why the next step in writing a program with CODE Editor is to use the Verifier.

The Verifier

The Verifier checks more th
an each source code statements syntax. For instance, after
fixing the syntax error on line 6 (figure 20), program SAMPLERPG would be
syntactically correct. However, the program would not compile because there is a non
syntax related error. To find the e
rror, run the Verifier by clicking on ACTIONS,
VERIFY PROGRAM, and then NO PROMPT. The Error List will be displayed with a
short explanation of the program problem(s) (figure 23). To display more detailed
message information about any message, move the c
ursor over the message and press F1.

You should be so lucky and only have one error! Most of the time, there will many error
messages. For instance, figure 24 shows an error list screen for the ITEM file DDS
source code definition (from figure 21).

Introduction to the AS/400

CODE Editor


Figure 23

Figure 24

One problem with the error list is that the error messages are not associated with the
responsible source code statements. You can “tie” the error messages and source code

Introduction to the AS/400

CODE Editor


s together by setting the error list options to ALL (click on OPTIONS,
MESSAGES, and then ALL) and then clicking on any of the error messages. Figure 25
shows the result of following the procedure and then clicking on the 3

error message.

Figure 25

Notice that the error messages are inserted after the source code statement that caused
them. However, there is still a similar problem as with the error list screen: we still don’t
know exactly what caused the error. CODE Editor tried to hel
p (a little) by highlighting
(in black) and moving the cursor to that portion of the DDS statement that pertained to
the third error message (the error message we clicked on). However, there are no clues
that relate the other 4 messages to their cause. W
e could click on each error list message
and see where the cursor is placed but this would be very time consuming. Fortunately,
the Verifier has a “source listing” option that is very useful.

Figure 26

To access the Verifier options,

A language specific Verifier
tions dialogue box will be
displayed. Figure 26 shows the
DDS options.

Click on the Create a source
listing option and then the Submit
button. Figure 27 shows the
source listing.

Introduction to the AS/400

CODE Editor


Figure 27

Within the so
urce listing, the Verifier assigns a unique letter to each source code
statements’ error messages (an “a” is assigned to the first error message, then a “b” is
assigned to the second, then a “c”, etc.). In figure 27, notice the vertical yellow arrow
ing at the assigned letters a, b, c, and d for line 11’s four errors. (In the error
message, the assigned letter appears after the error code number and before the error code
severity.) The source listing also contains a new line (after each incorrect so
urce code
statement) that positions the error letter(s) beneath the offending area within the source
code statement. The horizontal yellow arrow points at line 11’s. Finally, we (with the
help of CODE Editor) have pinpointed the location of the error wit
hin the statement!

To exit the source listing and return back to the edit session, click FILE and then CLOSE
VIEW. You may be prompted to save the source listing. Generally, you will click the
No button and not save the listing. (After seeing all stup
id errors you will want to erase
all evidence!)

If the verification is successful, the source code will compile. You might be wondering
why the Verifier doesn’t generate the executable code as compiling does. The reason is

it’s faster to veri
fy the source code then to translate into machine language.
Traditionally it takes a programmer many attempts to successfully compile the source
code. Each time a compile is submitted, the programmer must wait for the code

Introduction to the AS/400

CODE Editor


translation to be performed/att
empted. With verification, there is no attempt at
translation. The source code is checked and the errors are displayed immediately.

The Verifier has sped up and greatly simplified the debugging process in other ways also.
For instance, verification is
done interactively in real time rather than in batch (like
compiling). Also, instead of generating a spool file (containing the compilation listing)
and requiring the programmer to:

1. Display the spool file list (WRKSPLF)

2. Choose the option to display

the compilation listing

3. Page down to find the error messages

the verifier immediately displays the error list.

However, because CODE400 is running on a PC, there are some drawbacks. For
instance, when verifying a program, the Verifier insures that
the record layouts of all files
match what the program is expecting (this process is called level checking). The problem
is that the files are on the iSeries not on the PC. In other words, to perform the level
check, the Verifier must access the file inf
ormation on the iSeries. Uh

Accessing the iSeries takes time, which will slow up the verifier. Fortunately, the
Verifier will usually be configured to automatically make the connection to your iSeries
and get the required information. However, if

the iSeries is inaccessible the error
message in figure 28 will be displayed.

Figure 28

Introduction to the AS/400

CODE Editor


Assuming that the iSeries connection is available, figure 29 shows the results of verifying
a simple DDS definition that fails due to level ch
ecking. In this case, the physical file
ITEM (which the logical file KITEM is based on) that supposedly resides on an iSeries in
the library YOURLIBXX is not there. When the KITEM source code was verified, the
Verifier automatically went out to YOURLIBXX

and checked to see if the file ITEM
existed. ITEM didn’t exist so the verify had an error.

Figure 29

Now this is where things start getting complicated. If ITEM did exist, but the connection
was not available we still could not verify

the code. Also, what if we wanted to enter and
verify our source code on a laptop PC without an iSeries connection? That’s right, we’re
out of luck. Fortunately the CODE400 developers have created a method (called
caching) that allows programmers to dow
nload the information from the iSeries, save it
on the PC and then uses it for verification. Caching not only avoids the iSeries
connection requirement but also speeds up the verification by storing the information on
the PC.

Caching is another option

available on the Verifier options dialog box (figure 26). Select
caching by clicking the Use cache checkbox, then verify the code by clicking the Submit
button. The ITEM file information will be downloaded to the PC.

Caching can get a little tricky,
so be careful. Selecting caching tells the verifier to use
cache rather then connecting to the iSeries. So, if the ITEM file were deleted or changed
on the iSeries, the KITEM verification (using cache) would be successful but the code
would not compile o
n the iSeries. This is why you want to refresh the cache. When you
select caching, the Refresh cache checkbox is activated. It’s a good idea to periodically
select the option so that any changes on the iSeries will be captured.

Of course, all this is a
cademic if the source code and objects don’t exist on the iSeries.
So, that brings up the question

how do we access source code on an iSeries using CODE

Introduction to the AS/400

CODE Editor


Accessing an iSeries

There are several ways to identify the iSeries to WebSphere. The s
implest is to click the
Start button (in lower left of your Windows desktop), then select IBM WEBSPHERE
TCP/IP SERVER LIST (see figure 30).

Figure 30

Figure 31

This will result in the
Define TCP/IP Server
List window being
yed (figure 31).

To add an iSeries to
the list click the Add
button. This will bring
up the Add TCP/IP
Sever dialog box
(figure 32).

Introduction to the AS/400

CODE Editor


Figure 32

Click the Close button and you have successfully identified the iSeries to WebSphere.
To access information on the iSeries, you must also specify an iSeries userid and
password. If you try to retrieve so
urce code, CODE Editor will prompt for the userid
and password. However, it’s easier and faster to define the userid and password once.
You can do this by clicking the Start button, choosing IBM WEBSPHERE
SERVER LOGON. The Define Server Logon window will be displayed. Click the Add
button to display Add AS/400 User dialogue box. You will need to enter the user id,
password (twice), and select the iSeries location that this user id will be use
d for (see
figure 33).

Figure 33

Click the OK button and then the Close button (on the Define Server Logon window).
You will need to reboot the PC for the changes to take effect but then you are ready to

When you start u
p a CODE Editor session and try to save source code, a new option,
OS400A (representing the iSeries previously defined), will appear in the left pane of the
Select File

Save As window (figure 34).

Click the IP Address radio
button to activate the IP
address text field. Enter the
IP address into the text field
d click the OK button.
The Define TCP/IP Server
List window will be
redisplayed with the iSeries
IP address.

Introduction to the AS/400

CODE Editor


Figure 34

One last parameter we w
ant to modify is the library list that CODE Editor will use when
accessing the iSeries. CODE Editor uses the server login user id (that we specified
earlier) along with a default library list. Specifically CODE Editor uses all the system
and product lib
raries specified in the default library list, as well as, the current library
specified in the server logon user id profile. Usually, programmers will modify this to
include other frequently used libraries. For instance, assuming that YOURLIBXX is
d as the current library for the INTROXX, we would also want to add ECLXX to
the CODE Editor library list.

An easy way to define/change the library list (as well as, any of the communication
parameters we discussed above) is to access the CODE400 Daemo
n properties. A
Daemon is a PC based program that enables communication between the PC and an
iSeries. You can view and change the communication properties by right clicking on the
CODE400 Daemon icon in the Windows’ taskbar application tray (see figure


Figure 35

A pop up menu will be displayed. Select PROPERTIES to display the Communications
Property dialogue box (figure 36). Notice in the work pane that there is a tree diagram
with several communication options. Click the Libra
ry List option to display the library
list work fields. To add a library, enter the library name in the Library text field (at the

Introduction to the AS/400

CODE Editor


Figure 36

bottom of the dialogue box, see figure 37) and click the Add button. The library name
will be moved to the User Libraries pane and added to the library list.

Figure 37

Now, back to saving the source code. When you click the OS400A plus box (in the
Select File

Save As dialogue box), the tree diagram will expand

to display the Library
List we just modified/specified. You can continue to drill down the hierarchy to find an
already existing member to hold the source code (figure 38) or create a new member, by
specifying a new member name in the file name text area

of the Select File

Save As

Introduction to the AS/400

CODE Editor


window. We have specified a member called SUCCESS within YOURLIBXX/CLSRC
(figure 39).

Click the OK button and the source code will be saved to the specified member.

To prove that the source code is in the member, start a
5250 emulation session on the
iSeries and try to access the member SUCCESS using SEU. Figure 40 shows the result
of trying to edit the member using option 2 from the Work with Members Using PDM

What’s going on?

Well, we forgot that we are stil
l editing the source code in CODE Editor. To edit the
member on the iSeries we first must close the CODE Editor edit session. Figure 41
shows that the source code really is in member SUCCESS (on the iSeries) and that we
modified the message. (In a litt
le while, this change will help us prove that CODE Editor
can also retrieve iSeries source code.)

Figure 38

Introduction to the AS/400

CODE Editor


Figure 39

Figure 40

Introduction to the AS/400

CODE Editor


Figure 41

Assuming that we sav
ed the source code (with the modification) using SEU, lets now
access the code using CODE Editor. After starting the edit session click on FILE, then
OPEN, to display the Select file

Open for Edit dialogue box. Drill down through the
tree diagram to fi
nd the member SUCCESS. Notice that the library list contains ECLXX
(figure 42), which we defined earlier. To start an edit session for a member, you can
double click the member name or single click the member name (to select it) and click
the OK button.

Using either method for member SUCCESS will result in Figure 43.

Notice that the source code contains the changes we made using SEU on the iSeries.
This shows that we are indeed accessing the source code on the iSeries and not some
cached file on the P


Depending on the source code type and where it is stored, CODE Editor determines if
and where the compiling will be done (i.e. on the PC or an iSeries). For instance, any
source code types associate exclusively with the iSeries (CLP, PF,
etc.) cannot be
compiled on the PC. Figure 44 shows the drop down ACTION menu that is displayed
for the ITEM files DDS definition when it is stored on the C drive within the
AS400STUFF directory. Notice that the COMPILE option is inactive.

Introduction to the AS/400

CODE Editor


Figure 42

Figure 43

This type of source code must be compiled on an iSeries. Figure 45 shows the
ACTIONS drop down menu for the ITEM file source code when stored in
ECLXX/DDSRC on an iSeries. Notice that the COMPILE option is a

To compile the code, select the NO PROMPT option. The prompt option gives you a
series of dialogue boxes that allow you to specify all the parameter values of the CRTPF
command. If the compilation is successful, a message similar to that in
figure 46 will be

Introduction to the AS/400

CODE Editor


Figure 44

Figure 45

Figure 46

Introduction to the AS/400

CODE Editor


For PC based programs, follow the same procedure to display the compile options and
select one.

Compiling (and other system functions) can als
o be performed from the command shell.
An independent, full screen command shell session can be started from any edit session
by pressing F9. Alternatively, choosing a menu option that includes “…and show
command shell” will create a half screen command

shell session. While in the command
shell, you can shellect (sorry, I couldn’t resist) which server the commands should be
issued to.

For instance, Figure 47 shows the command shell displayed when F9 is pressed. Notice
that the default drive is
. This simply means that the command shell server is
an iSeries. CL commands that display a screen (DSPXXX, STRPDM, etc.) are not valid
and no results will be shown. However, any commands that don’t require an interactive
screen (i.e. ADDLIBLE, CRTS
RCPF, CRTRPGPGM, etc.) can be issued. The
capability to issue CL commands from a CODE Editor session can be very useful. For
instance, if you wanted to create a new source physical file to hold source code, you
wouldn’t have to start a 5250 emulation se
ssion. You could simply create it the
command shell.

Figure 47

Introduction to the AS/400

CODE Editor


To control the command shell server, right click anywhere in the command shell pane
and a pop
up menu will be displayed. At the bottom of the menu a list of the availab
servers will displayed and can be selected. Click on LOCAL and the command shell will
emulate a Command Prompt session on a PC.

The LOCAL command shell does support display commands. Notice in figure 48 that a
directory command for the A drive was
issued and the resulting file list was displayed in
the shell. Notice, also that the default path is the location of the WebSphere
Development Tools files and that all the CL commands we issued earlier are still

Figure 49 shows the command s
hell after selecting ACTIONS, RUN LOCAL, and NO
PROMPT AND SHOW COMMAND SHELL. There are several important things to
point out regarding this RUN function. First of all, notice that we didn’t identify the
executable code. We were in the source code when

we issued the command and the
system “knew” which executable file to run. (In this case, the program displays a frame
with a combination box that contains application function options). Secondly, the screen
was split into two windows with the command s
hell occupying the lower window. You
can toggle between the windows by simply clicking any where in either window. Finally,
notice that the command shell still displays a log of all previous shell activity.

Figure 48

Introduction to the AS/400

CODE Editor


gure 49

Other Functions

Besides allowing programmers to create applications on a PC, CODE Editor has several
other popular features. If you are new to programming you may not appreciate several of
these options. However, as you gain more programming ex
perience you will ooh and aah
over these features like the rest of us nerds.

Probably the nicest CODE Editor feature is the ability to split the edit screen vertically.
Previously we demonstrated a horizontal screen split that displayed two separate e
sessions. Horizontal splits actually reduce the overall viewing area available. Vertical
split increase the number of lines of code displayed. Notice in figure 50 that 80 lines of
code are displayed.

To vertically split the screen, first click on

VIEW, SPLIT, and then VERTICAL. This
will set the splitting mode to vertical. Now when a new view is created (by clicking on
VIEW, SPLIT, and then VIEW), the new edit session will appear to the right of the
original session.

CODE Editor also provides
control over many aspects of the session appearance. For
instance, within the VIEW menu is a LINE NUMBER option. (Clicking the option
toggles it on and off.) When the option is off, line numbers will not be displayed.

Introduction to the AS/400

CODE Editor


Figure 50

I can
hear you yawning, but look at the difference in the appearance when we vertically
split the screen (figure 51). Notice that much more of each line of code can be
displayed, thereby increasing the total editing area.

You can also control what is displa
yed in the window frame. For instance, on the
OPTIONS menu there are entries for FILE LIST and TOOLBAR. Both of these have off
options that will delete the item from the screen and, again, increase the amount of source
code displayed. The CONTROLS optio
n (in the OPTIONS menu) also has entries to
suppress the command, format, status and message lines.

There are also many options that are source code specific. For instance, with RPG there
is an automatic indentation option that is very helpful in fin
ding missing ENDS, as well
as, a NAVIGATOR VIEW that provides a graphical representation of a programs logic.
For JAVA code, there is an OUTLINE LOGIC view that “skinnies down the code” to
decision statements and method headers. This provides a rudimenta
ry overview of a
programs functions. Another example of a language specific option is the SHOW option
for DDS code. SHOW filters out statements based on specification type (record level
specs only, key specs only, etc.). This allows the programmer to ea
sily zero in on
specified sections of the source code.

Introduction to the AS/400

CODE Editor


Figure 51


CODE Editor provides most of the same capabilities as PDM and SEU, the native iSeries
application development tools. For instance, CODE Editor provides source code e
and syntax checking but also provides features such as vertical screen splitting, edit
session appearance control, and source code tokenizing. Most importantly, programmers
can create iSeries applications on a PC disconnected from an iSeries. Whe
n connected to
an iSeries, source code can be saved and retrieved from either a PC or an iSeries. CODE
Editor also permits both PC commands (DIR, MD, etc.) and iSeries CL commands to be
executed from the Command Shell

a very powerful and useful feature.

CODE Editor does have some shortcomings. Prompting is not supported for many
programming languages and the CL prompting is cumbersome to set up and use.
However, the advantages far outweigh these few drawbacks, making CODE Editor the
preferred develop
ment tool.