From: Chris Ringer To: All
I have a question regarding S/36 to AS/400 migration. On a workstation input field defined as number (data type D) and adjust fill with blanks (B), the S/36 reads the field as numeric. If my field's value is actually bbb10, is the workstation passing back 00010 or bbb10 if my program has the input field defined as numeric? If bbb10 is being passed back to the program, the S/36 of course reads this as 00010. What happens in the case of the AS/400? Is the field bbb10 passed back as 00010 or bbb10?
From: Ernie Malaga To: Chris Ringer
When you define a numeric input-output field, you can define an edit code or edit word on the display file; when a number is presented in the field, it will be edited (so that a date might show as 08/16/91, slashes and everything). You simply enter the number, and you can press either Enter or Field+ or Field- or Field Exit--it doesn't matter. The field will be correctly interpreted by the system, even if the digits haven't been "shifted" to the right end of the field. On the S/36, if you have a seven-digit numeric field and you type in a number 1 and press the Forward Tab key, the "1" remains at the left end of the field, where it will be read by the program as 1,000,000 instead of 1. The AS/400 doesn't do that.
From: Tim Johnston To: Chris Ringer
Let me add one more small detail to what Ernie said. You mentioned numeric data being packed. On the S/36, the I-specs had to determine whether the field was packed or not. I would love to have a dollar for every time I had 4040404 on a report. That was where I forgot to specify packed in the input specs. On the AS/400, if you choose to create a physical file with DDS, then the system takes care of the packing. For example, if you describe a field as a six-digit numeric (such as a date), the AS/400 automatically places the field in a four-byte packed field, but the specs created by the externally described file only show six digits. Ever have to use a data structure or MOVE or Z-ADD to get the seven-digit packed field into a six-digit field? You don't have to do it on the AS/400.
From: Allyn Uptain To: Tim Johnston
While we're talking about AS/400 numeric screen entry, let me ask you this one. I have several programs (on the S/36) that define a screen field as both numeric and alpha--the field is specified twice in the RPG program. Can the AS/400 handle that? The reason for doing this is so the program can tell if anything was keyed in by the operator. Blank fields are filled in by the program, while keyed fields are not. This allows the operator to key a 0 when forcing a field to remain 0 even though the program would normally calculate some amount for that field.
From: Tim Johnston To: Allyn Uptain
Yes and no. Yes, it does handle it, but not naturally. On the S/36, we had to key all of our I-specs, or keep source members of the file layouts for DFU and programs and pull them into our programs. On the AS/400, you can still do that if you want to, but I can also drive to work in my Chevy Blazer on three wheels. The point is that this is the hard way to do it. Using Data Description Specs (DDS), you specify all the fields that you want in your file, sizes, numeric or alpha. Then you simply use the Create Physical File (CRTPF) command to create that file. When the file is created, the field sizes and characteristics are now a part of that file (have you ever used dBase? It's the same idea). When writing the RPG program, in position 19 of the F-spec, you put an E to designate externally defined, instead of the old "F" which means program described.
The display screens are the same way, they too are written with DDS. As a matter of fact, when you compile the screens, a Display File is created which has the same rights and privileges (as far as the program goes) as the physical files. It can also be externally described.
Anyway, back to your question... Yes, the AS/400 can handle it. You can-- either in native or S/36E--key the I-specs in manually. I don't know how you could perform those checks with externally described files. That would take some serious thought.
Don't forget, there is a S/36 Environment that performs similar to the S/36. I have some code that is running in the S/36E, and it was originally written for the System/3. The only modifications to some of the code was simply changing the device in the F-Specs from Multi-Function Card Unit (MFCU) to DISK.
From: Ernie Malaga To: Allyn Uptain
Another solution to your problem, strictly native (using external file definitions), is to use the CHANGE keyword in the DDS of the display file. You can define your display input field as strictly numeric with CHANGE(50), for example. If (and only if) the field is changed by the user in any way (by entering a number, or changing the one that's there), indicator 50 will turn on. Your program can detect that and act upon it. It's a helluva lot easier than doubly defining the field in your program, and you don't run the risk of having alphanumeric entries in a field you want to be numeric only.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online