Avoiding That Annoying Dial-up Window with TCP/IP
Is your AS/400 configured to use TCP/IP? Are you using Client Access/400 to establish a TCP/IP 5250 connection? Are you thoroughly annoyed by that “Connect to” window asking you whether you want to dial up an ISP every time you attempt to connect to your AS/400? I was, too, until I figured out what was going on. If you’re getting this window every time you start TCP/IP services on your PC by attempting to connect to your AS/400, your PC probably has Microsoft Internet Explorer (IE) installed with the AutoDial feature enabled. You can disable this feature, but I’ll warn you up front that you may have to perform some surgery on your Windows registry; therefore, this technique is not for the faint of heart!
If you’re using Version 3.0 of IE, you’re in luck because you can disable the AutoDial feature by opening the Control Panel and then clicking the Internet icon. Once there, click the Connections tab and uncheck the “Connect to the Internet as needed” box. For those of you with IE 4.0 or later, you can try this first method, but if it doesn’t work for you then it’s time to get out your scalpel. Before you do, though, you really should back up your registry first to avoid problems in the future. For great tips on backing up your registry, point your browser to support.microsoft.com/support/serviceware/office/mso2000/3lbti6f4.asp and, for a link on how to restore your backed up registry, visit support.microsoft.com/support/serviceware/windows/win95/e9j2hsrdr.asp.
OK, now that you’ve backed up your registry, click the Windows Start button and then the Run button. Now type in REGEDIT and click OK. The Windows Registry Editor window will open. In this window, you can search for all the keys that contain the registry key EnableAutoDial (the key that needs to be changed) within the registry by pressing F3. When the Find window appears, enter EnableAutoDial and click OK. If you don’t want to do the search routine, you can locate each key manually. The appropriate keys and values you should change them to are shown in Figure 1. Change these key values, and your AutoDial problems with Client/Access 400 TCP/IP services will be a thing of the past!
— Shannon O’Donnell Senior Technical Editor
Midrange Computing
Registry Path Change EnableAutoDial Key...
HKEY_CURRENT_USERSoftwareMicrosoft Windows CurrentVersionInternet Settings from 01 00 00 00 to 00 00 00 00
HKEY_LOCAL_MACHINEConfig001SoftwareMicrosoftWindowsCurrentVersionInternet Settings from 01 00 00 00 to 00 00 00 00
HKEY_USER .DefaultSoftwareMicrosoftWindowsCurrentVersionInternet Settings from 01 00 00 00 to 00 00 00 00
HKEY_CURRENT_CONFIGSoftwareMicrosoftWindowsCurrentVersionInternet Settings from 01 00 00 00 to 00 00 00 00
Figure 1: Change these registry key values to disable the Windows AutoDial.
Efficient File Conversion
We recently made some enhancements to a purchased package, including adding a single field to a large file, but converting the production file to the new layout caused some pain that we could have avoided. The traditional approach, which we used, was to remove the logicals, rename the existing file, create a new file, use CPYF *MAP *DROP to copy in the data, and then re-create the logicals. We had an 8-hour install window and didn’t give this file conversion a second thought. Six hours into the install, however, the only thing still running was the copy. An analysis of the I/O counts indicated that the installation would run for another 12 to 13 hours, and we still had to rebuild the logicals after the copy finished.
Consequently, the installation had to be aborted so production wouldn’t be impacted.
The boss wasn’t happy, so, on Monday, my mission (which I had to accept) was to shoehorn a 15-hour-plus file copy into 8 hours. There turned out to be several approaches to and permutations of this file conversion. The shortest technique took just over an hour, and the longest technique, which was also the traditional approach, took well over 15 hours. The lesson here is that paying attention up front can save some embarrassment when you work with large files.
Obviously, “large” is a relative term, and your perception is influenced by your processor speed, memory, disk configuration, etc., so you have to decide for yourself when to be concerned about conversion times. In my case, the file had nearly 8 million records, 473 fields, and a record length of just over 2,000 bytes. In addition, the physical file was unkeyed and had four logical files.
The first thing I tried was blocking the Copy File (CPYF) command, as blocking can often improve runtimes if you are not memory-constrained. We were on V4R3, so I divided 128K by the record size and came up with a blocking factor of 58. I started a blocked CPYF, but just watching the I/O counts made it obvious that blocking wasn’t going to be the solution and that this was going to be more complicated than I had thought.
In a test library, I created scaled-down versions of the physical and logical files, consisting of 10 percent of the records, and started testing. All of my tests, except the Change Physical File (CHGPF) command, included deleting and re-creating the logical files, since this was an essential part of the conversion process. I figured there were three things to try: CPYF with blocking, custom RPG with blocking, and CHGPF.
As it turned out, there was another significant variable to consider: the position of the new field in the record. I had inserted the new field in a logical position close to the beginning of the record, but the conversion always went faster when the new field was added to the end. If I put the new field at the end of the record, CHGPF was by far the best way to convert the file, especially since, in this case, no logical files needed rebuilding. For
an inserted field, it turned out that a custom RPG cycle program was most efficient and that CPYF was by far least efficient.
Given my available install window, I choose to insert the field in a logical position and use an RPG program. You can review the results of my tests in Figure 2. The actual install time was almost exactly the 3.2 hours my tests had predicted.
From this experience, here is what I learned about changing large files:
• Add new fields to the end of the record if possible.
• Convert using CHGPF when fields are added to the end.
• Convert using a custom RPG program with blocking when inserting a field.
• CPYF is usually the most inefficient conversion method.
• When in doubt, test a small subset of your data to determine the trends.
— Sam Lennon
Editor’s Note: Avoid database changes to purchased packages. Making changes causes problems when upgrading to new patch levels and releases. Tag files that point to the package files via a common key are a much better and more maintenance-free solution.
Method New Field Location Minutes for 10% Extrapolated Hours
CHGPF End 7 1.2 hours CPYF *MAP Block-58 End 29 4.8 hours CPYF *MAP *DROP Block-58 End 30 5.0 hours CPYF *NOCHK Block-58 End 43 7.1 hours RPV IV, cycle, Block-58 Inserted 19 3.2 hours CHGPF Inserted 72 12.0 hours CPYF *MAP Block-58 Inserted 91 15.1 hours Notes:
• Results with a keyed physical will probably differ.
• Testing was done on a four-way 530 with other users on the machine.
• Test results are not scientific but are intended to show trends; most tests were run only once.
• There may be other techniques not tested.
Figure 2: These were the results of inserting a field in a logical position and using an RPG program to change a large file.
STATICally Speaking
Recently, we discovered an “undiscovered feature” in RPG IV and STATIC variables. When a STATIC variable is used in a procedure, its value is not reinitialized, even if the program ends with *INLR=*ON and is called again later. So even though module-level data variables are reinitialized each time the program ends with *INLR=*ON and is called again, STATIC procedure variables are never reinitialized, at least not as long as the
variables continue in memory for that job. If you use STATIC variables, take note of this tip; it could save you some headaches later on!
— Bob Bordeaux
String Manipulation Made Easy
Here’s a basic CL string manipulation tip: CL documentation shows that, when changing a variable, it is possible to use a portion of another variable to change your target. So if the value of &TARGET is ABCDEFGH and the value of &SUBJECT is 12345, the following command string would result in a value of 2345bbbb for &TARGET, where b=blank:
CHGVAR VAR(&TARGET) +
VALUE(%SST(&SUBJECT 2 5)
What is not so well-known is that you could change a portion of the target, as opposed to changing the entire variable, by using the same technique reversed:
CHGVAR VAR(%SST(&TARGET 2 5)) +
VALUE(&SUBJECT)
In this case, the resulting value would be A12345GH. I have found this technique particularly useful in setting up Open Query File (OPNQRYF) shells where the number of variables to be used is unknown.
— David G. Abramowitz
Save Ink!
I have a tip that improves on the September 1999 TechTalk tip “Capturing the Elusive AS/400 Screen.” In my Client Access color mapping, I set the screen color to white and change the field colors to black (or any dark color). When I print these screens, they are easier to read, and I use less ink.
— Tim Cortez Worley Warehousing, Inc.
What Page Are You On?
I just read the October 1999 TechTalk tip “Changing the Code Page of AS/400 IFS Files,” and, actually, converting the code page (i.e., translating EBCDIC to ASCII) of a file on the AS/400 Integrated File System (AS/400 IFS) is much simpler than the tip describes it. You can simply run the Copy to Import File (CPYTOIMPF) command and then use the Move (MOV) command, specifying the OBJ and TOOBJ parameters with the TOCODEPAGE(*PCASCII) and DTAFMT(*TEXT) parameter values. Doing this will convert the file “in place.” Here is an example:
MOV OBJ(‘mydir est.ebc’) +
TOOBJ(‘mydir est.txt’) +
TOCODEPAGE(*PCASCII) +
DTAFMT(*TEXT)
I have written a utility that addresses this EBCDIC-to-ASCII conversion issue as well as the issue of using the AS/400 IFS directory structure in development, test, and production environments. Figure 3 shows the Copy to (AS/400) IFS (CPYTOIFS) command. On the Web at www.midrangecomputing.com/mc are the command processing program (CPP) CPYTOIFSC and the help panel group for the command. To execute the command, enter CPYTOIFSC on a command line and press Enter. This utility will handle all of your AS/400 IFS copying needs.
Here are some things to keep in mind when using this utility:
• The command includes the “Order prompt is displayed” value for the PROMPT keyword of the last PARM statement (FROMMBR). This allows the FROMMBR keyword, which is a default value, to be listed before the other parameters that have required fields when the command is prompted. Note, too, that the CL therefore lists parameters in the same order as the command source.
• The MOV statement handles the conversion of EBCDIC to ASCII on the AS/400 IFS.
• QDLS is allowed, since the SNDDST TYPE(*DOC) command can be used to send an email with an AS/400 IFS file as an attachment only if it is in the QDLS file system.
• The first seven characters of the group profile are used as the “Environment” directory, since that is a standard in our shop. The directory could be changed to use all 10 characters of the group profile or even to use the special value “~” with the group profile appended as the first characters of the path to use the group profile’s “Home” directory as specified in the Create User Profile (CRTUSRPRF) command.
While I was working on this code, I made a few hard-won discoveries that I’ll share with you here so you won’t have to attend the School of Hard Knocks like I did. When a CLP is written to copy an AS/400 file to an ASCII-delimited file on the AS/400 IFS, it is usual for the programmer to hardcode the directory to which the file is being copied. This is a problem in structured environments where a given program uses the library list to access files based on the current environment (test vs. production, for example). At my company, I have created a set of rules that define specific AS/400 IFS directories to use based on the environment. The environment is defined using the current user’s group profile. This provides a separate “environment” for AS/400 IFS directories when in test vs. production. See the structure below:
MYAS400
PRODGRP
Application1
Application2
Application3
TESTGRP
Application1
Application2
Application3
PGMRGRP
Application1
Application2
Application3
When you develop a new application that requires an AS/400 IFS directory, that directory is created under each environment directory. Using the CPYTOIFS utility
included here, you can easily copy files and objects from one environment to another without the need for hardcoding paths.
— Michael Hagey
/*===================================================================*/
/* To compile: */
/* */
/* CRTCMD CMD(XXX/CPYTOIFS) PGM(XXX/CPYTOIFSC) + */
/* SRCFILE(XXX/QCMDSRC) HLPPNLGRP(XXX/CPYTOIFSH) */
/* */
/*==================================================================*/
CMD PROMPT(‘Copy To Standard IFS File’)
PARM KWD(FROMFILE) TYPE(QUAL1) MIN(1) +
PROMPT(‘From file’ 1)
QUAL1: QUAL TYPE(*NAME) LEN(10) MIN(1) EXPR(*YES)
QUAL TYPE(*NAME) LEN(10) DFT(*LIBL) +
SPCVAL((*LIBL) (*CURLIB)) PROMPT(‘Library’)
PARM KWD(TOSTMD) TYPE(*PNAME) LEN(50) MIN(1) +
PROMPT(‘To stream directory’)
PARM KWD(TOSTMF) TYPE(*CHAR) LEN(8) MIN(1) +
PROMPT(‘To stream file’)
PARM KWD(MBROPT) TYPE(*CHAR) LEN(8) RSTD(*YES) +
DFT(*ADD) VALUES(*ADD *REPLACE) +
PROMPT(‘Replace to add records’)
PARM KWD(CVTOPT) TYPE(*CHAR) LEN(4) RSTD(*YES) +
DFT(*CSV) VALUES(*CSV) PROMPT(‘Conversion +
option’)
PARM KWD(FILESYS) TYPE(*CHAR) LEN(5) RSTD(*YES) +
DFT(*ROOT) VALUES(*ROOT *QDLS) +
PROMPT(‘File system’)
/* FROMMBR placed here but is prompted after FROMFILE */
/* This is so &FROMMBR can have a default before required &TOSTMD */
PARM KWD(FROMMBR) TYPE(*NAME) LEN(10) DFT(*FIRST) +
SPCVAL((*FIRST)) PROMPT(‘From member’ 2)
Figure 3: CPYTOIFS is used to copy AS/400 IFS files and perform EBCDIC-to-ASCII conversions.
Hands off the Passwords!
Do you have a problem with people using either the AS/400 or Windows to make unauthorized password changes to AS/400 profiles? Here’s a simple solution: Create a password validation program. Every time someone attempts to change an AS/400 password, the system will pass four parameters to your new validation program:
• The new password 10a, which has a length of 10 alpha
• The old password, which has a length of 10 alpha
• A return code, which has a length of 1 alpha
• The user profile, which has a length of 10 alpha
In your password validation program, find the user profile you don’t want changed and set the return code value to 1. When processing returns to OS/400, the system will not accept the requested password change and an appropriate message will be sent to the user. If the return code parameter shows anything other than a 1, the change will be accepted.
One final note: Don’t forget to change the system value QPWDVLDPGM (Password Validation Program) to point to the new program you created. Also, be aware that the data, including the password, is passed as unencrypted text. So make sure you apply the proper security!
—Greg Leister DesignSystems Inc.
LATEST COMMENTS
MC Press Online