When i am the first user to sign on the Virtual device name of the system has to be QPADEV001, but this is not so in my case, so i would like to know whats the problem?
Also i would like to know the carreer opportunity in As400(Iseries) in abroad and the salaries? Job sites have not a much option.
<i>i would like to know why those sessions are missing. </i>
Terminal devices with names like QPADEV0001 and QPADEV0002 are usually created automatically by the system.
A PC sends a terminal connection request to the AS/400. Part of the request is a description of the kind of terminal that should be used. The request might ask for a terminal that only supports screens that are 80 characters wide or it might ask for 132 characters wide. It might ask for a monochrome or a color terminal. It might ask for a number of different attributes by asking for a particular terminal type.
The AS/400 looks at the different QPADEV* devices that have been created to see if any of them are the right type. If it finds one, it checks to see if it’s in the proper state (varied on). If a device matches everything, then that device becomes associated with the interactive job. If it doesn’t find one, then it simply creates a new device, like QPADEV0003.
However, it will only automatically create new devices if the system configuration allows it. The most critical system value is QAUTOCFG to control if new devices are allowed to be created. Then there is QAUTOVRT to control the maximum number of devices to create automatically. (There are a few other possible elements, but those are what affect most sites.)
If the QAUTOCFG value is turned on but the QAUTOVRT limit has been reached, no more virtual devices will be created automatically.
So, the system can react differently. If it finds a device that is in the proper state but the terminal type doesn’t match, it will delete the device and create a new one with the same name. The new one will have a terminal type that fits the latest connection request. An existing device like QPADEV0001 might be a 132-character terminal device today; but it can be an 80-character device tomorrow. A connection request for a 132-char device will skip over QPADEV0001 tomorrow even if it connected to it today.
Also, different subsystems might allow the same devices to attach to them. Asd subsystems are started, they try to allocate all of the devices that are defined to be allowed in them. The last subsystem to allocate a device is the one that gets it.
But there are complications. The timing of allocations can be tricky. Two subsystems starting at the same time might process the list of devices at slightly different rates. Other elements such as auto-start jobs in one subsystem or memory pool assignments can cause the first subsystem to be a little slower. It might take longer for it to process devices. So even if it’s the first to start, it might be the last to try to allocate a particular device. Maybe that device will be allocated to MYQINTER instead on some days for almost random reasons.
Or maybe a PC user had trouble with a password. After trying a few times, the user profile was disabled and the device was varied off. QPADEV0001 won’t be available if it’s varied off.
In short, the sequence of devices can be practically impossible to predict. In order to guarantee a sequence, some significant programming is needed to ensure that all related events happen in the same order and all conditions start in the same state.
Usually it’s easiest simply to use explicitly named devices and let the auto-configured virtual devices get handled however the system needs to handle them.